# dgk.labs — full post text > Concatenated markdown of published posts for LLM context. Prefer /llms.txt for an index. # How FocusAnalyze is built > The stack, the architecture, and the productivity principles driving the product decisions Author: D. Gopal Krishna Published: 2026-09-27 Category: product Tags: #focusanalyze #engineering #architecture #productivity URL: https://www.dgopalkrishna.com/posts/how-focusanalyze-is-built --- ## The shape of the system FocusAnalyze isn't one app — it's four clients sharing one backend: - **Web** (`focusanalyze-fe`) — Next.js, the primary UI - **Desktop** (`focusanalyze-desktop`) — Next.js + Tauri, for local focus tracking and offline support - **Mobile** (`focusanalyze-mobile`) — React Native + Expo - **Backend** (`focusanalyze-mind`) — Django + Django REST Framework, the API every client talks to All three frontends consume a single REST client generated from the Django OpenAPI schema, rather than hand-written API types. When a serializer changes on the backend, the client regenerates — no manual type drift, no docs going stale, no "works locally, breaks in prod" surprises from a client and server disagreeing about a shape. ## Underneath the API - **Postgres** for the system of record. - **Celery** for background work — reports, notifications, anything that shouldn't block a request. - **Keycloak** for authentication, shared across every client. - **Weaviate** as a long-term memory store, so the AI layer can learn preferences and patterns instead of starting cold every conversation. - **Google Calendar** as the source of truth for events, synced both directions. The AI assistant, FocusGPT, sits on top of this rather than beside it — it reads the same task/event/project models everything else does, and any action it proposes (scheduling a meeting, restructuring a plan) goes through a human-in-the-loop confirmation step before it commits. The AI is a collaborator with read/write access, not an opaque process making changes on your calendar without you seeing them first. ## The productivity problem, translated into architecture The product decisions map fairly directly onto specific failure modes I kept running into, in myself and in how most tools are built: - **Context switching overhead** → tasks, events, and projects live in one system instead of three, because the cost of moving between tools is not just time, it's the reset of working memory each switch forces. - **Time blindness** → the desktop app tracks actual focus time per app/project, because self-reported time estimates are unreliable in a specific, predictable direction — people underestimate how fragmented their day actually was. - **Planning friction** → FocusGPT lets you create tasks and events conversationally, because the gap between "I know what I need to do" and "I've entered it into a system correctly" is where a lot of planning intent quietly dies. - **Calendar conflicts** → the AI sees the full schedule before proposing anything, so double-booking is a check the system performs, not a thing you have to remember to do yourself. - **Context loss** → long-term memory means the system doesn't ask you to re-explain your preferences every session. None of this is exotic. It's mostly taking well-known failure points in how people actually work — not how project management tools assume people work — and building the architecture so the failure point isn't there anymore. ## What I'd change The generated-client approach and the shared backend across three platforms have paid for themselves many times over. The place I'm still iterating is the boundary between what the AI is allowed to do autonomously and what it should always surface for confirmation — that line moves as trust in the system's judgment (and mine, in how I've built it) increases. ---------- # Three years at Metacell: a reflection on software engineering > What the job actually taught me, and where I think the craft is headed Author: D. Gopal Krishna Published: 2026-09-27 Category: software Tags: #career #software-engineering #reflection URL: https://www.dgopalkrishna.com/posts/three-years-at-metacell-a-reflection-on-software-engineering --- ## Three years in Three years ago I joined Metacell not fully knowing what "software engineer" would come to mean once I was actually doing the job, instead of studying it. This is a reflection on what changed — in how I write code, how I think about problems, and what I now believe the next few years of this profession look like. ## What I thought engineering was, versus what it is Early on, I measured myself by output: lines shipped, tickets closed, features landed. Over time the job revealed itself to be mostly about judgment — deciding what *not* to build, reading a system well enough to know where the real risk lives, and communicating a tradeoff clearly enough that someone else can disagree with it intelligently. Code is the easy part. Knowing which code deserves to exist is the actual skill. ## The good - **Ownership compounds.** The projects where I was trusted to own a problem end-to-end — not just implement a spec — are the ones I grew the most from, because I had to live with the consequences of my own decisions. - **Working close to real systems teaches things tutorials can't.** Production incidents, migrations, and the slow decay of an under-maintained service taught me more about architecture than any course did. - **Good collaborators change your ceiling.** The engineers I learned the most from were not the ones with the most polished code, but the ones who asked the sharpest questions in review. ## The bad - **Velocity pressure can quietly erode judgment.** It is easy to ship the fast version of a decision instead of the correct one, especially under deadline pressure, and not notice the debt until much later. - **Not everything worth doing is visible.** Refactoring, deleting dead code, writing the doc nobody asked for — this work rarely gets credit in the moment, but it is often the difference between a codebase that stays healthy and one that doesn't. - **Burnout doesn't announce itself.** It shows up as declining curiosity before it shows up as declining output, and by the time output drops, it's already late to intervene. ## What I'd tell myself three years ago Optimize for the reps that teach you something, not the ones that look good on a resume. Ask more questions in code review than you're comfortable asking. And write down *why* a decision was made, not just what was decided — future-you and future-teammates will thank you. ## Where I think this is heading The mechanical part of engineering — boilerplate, glue code, first-draft implementations — is increasingly something you delegate to a tool rather than type yourself. That doesn't shrink the job; it shifts it further toward the parts that were always the hard parts: defining the right problem, evaluating whether a solution actually holds up, and taking responsibility for systems you didn't write every line of. Three years from now, I expect the engineers who matter most won't be the ones who type the fastest. They'll be the ones with the best judgment about what's worth building at all. ---------- # Building FocusAnalyze: the why > The story behind the idea — a review and how things are going now Author: D. Gopal Krishna Published: 2025-12-30 Category: neuro Tags: #focusanalyze #neurotech #product URL: https://www.dgopalkrishna.com/posts/building-focusanalyze-the-why --- ## Why this exists FocusAnalyze started from a simple frustration: I was deep in neurotechnology — signal pipelines, preprocessing, experiment tooling — and the “product” layer always felt bolted on. Researchers had powerful methods. Clinicians and builders had messy workflows. Somewhere between the lab notebook and a deployable system, clarity died. I wanted a place where **focus**, **signal quality**, and **decision-making under noise** were first-class. Not another dashboard for vanity metrics. A tool that helps you see whether attention (or the proxy you are measuring) is actually usable for the next step — training, clinical review, or product feedback. That is the why: **make cognitive / neural focus measurable enough to act on**, without pretending the science is solved. ## The idea in one sentence FocusAnalyze is my attempt to turn noisy physiological and behavioral signals into a workflow that a small team (or a solo builder) can run end-to-end — acquire, clean, score, review, ship. ## What I believed then Early on I assumed three things: 1. **The hard part is the model.** If the classifier is good, the product writes itself. 2. **Infrastructure should look “serious.”** Kubernetes, multi-service meshes, fancy orchestration — because that is what “real” products use. 3. **Users want depth.** More plots, more parameters, more knobs. All three were only half true. The model matters, but **trust and repeatability** matter more. A slightly worse score that you can explain and reproduce beats a magic number that changes every deploy. Infrastructure should match customer count and ops capacity — not LinkedIn aesthetics. And users want **clarity**: one primary signal of “is this session usable?” before they want twenty secondary charts. ## What changed Shipping forced humility. - **Preprocessing is product.** Bad filters and inconsistent epoching create more support tickets than a mediocre model ever will. - **Compose before cluster.** For early FocusAnalyze, Docker Compose on a single EC2 box was the honest architecture. I wrote about that separately — the short version is that Kubernetes is wonderful when you have the team and the traffic; it is expensive theatre when you do not. - **The “why” is also personal.** Building at the intersection of software and neuroscience is how I learn in public. FocusAnalyze is a product hypothesis and a lab notebook with a domain name. ## Where things stand now FocusAnalyze is still evolving. The north star has not changed: **help people reason about focus and signal quality without drowning in pipeline complexity.** The implementation details have: simpler deploy story, clearer session review, tighter feedback between what the science needs and what the UI shows. If you are building in neurotech or adjacent scientific tooling, the lesson I keep relearning is this — start from the decision a human has to make, then work backwards to signals and infrastructure. The why stays stable. The stack should not. ## Who this is for - Builders shipping BCI / neurotech prototypes who need a sane product path - Researchers who care about reproducibility as much as novelty - Anyone curious why I chose this problem over a safer SaaS niche I will keep writing as the system grows — architecture choices, failed experiments, and the boring operational truths that usually stay off blog posts. ----------