# 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.