Case 04 · Product design & development, solo · personal PWA

Baki
concept to shipped, every decision mine.

Stack · React + FastAPI · mobile-firstStatus · Running daily · not publicly launched

374

commits in two months

344

backend tests, green

components on 11 primitives

API endpoints · 28 tables

The short version

A strength-and-nutrition PWA with exactly one user — me — running daily on my phone.
I designed and built all of it: product, design system, frontend, backend, the coach.
The spine is one decision: a deterministic engine owns every health calculation, and the AI is only allowed to talk about it.
Living inside it is what found the bugs — a form nobody could answer honestly, a field that silently voided my training, an AI that claimed it had saved something it hadn't.

01 · What it is

A private personal trainer with exactly one user, on purpose.

Strength training and nutrition in one product, built on evidence-based principles and female physiology. It installs as a PWA on my phone and runs on a local server — private by decision, not by limitation. The riskiest assumption was never market size; it was whether the thing could support a real routine without becoming noisy. The question was never "how do I monetise this?" It was "what would I build if I had to live with every product decision I made?"

02 · The product decisions that matter

Before any screen, I had to decide what the product would never do.

Health above progress

AI communicates, doesn't calculate

Maintenance or recomposition — never a deficit

Product invariants — rules the product enforces even when the user would prefer it didn't.

Health above progress

The app watches for RED-S (Relative Energy Deficiency in Sport) and raises it before problems compound. A training goal never overrides a health signal.

AI communicates, doesn't calculate

Progression, nutrition totals, volume load and risk all resolve in a deterministic engine. The coach reads its output and puts it in plain language — it cannot overrule a rule.

Maintenance or recomposition — never a deficit

The product is opinionated on purpose: it checks that I am eating enough, not that I am restricting.

03 · The architecture decision, and why it was a design call

Deterministic engine + AI communication layer, not the other way around.

Option A · rejected

Let the AI decide

Fast to build, impossible to test.

Option B · chosen

Engine calculates, AI communicates

Deterministic, auditable, and the coach has no write access to it.

Option A

Ask an LLM to calculate progression, nutrition targets and health flags on the fly. The model hallucinates, drifts between sessions, and can't be audited when it says “eat less.”

Option B

All logic lives in a deterministic Python engine, consistent between sessions. The coach reads its outputs and puts them in plain language. When the engine says RED-S risk: 0.8, the coach raises a card — it cannot overrule it.

A product design decision that happens to have engineering consequences, not the other way around.

The day the rule proved itself

The coach said “logged”. Nothing was logged.

Problem

Asked in chat to “log this meal for me”, the coach replied “Logged: two eggs, toast, coffee.” The database said otherwise: nothing was written. The model had no tools — so it narrated an action it couldn’t perform.

Move

A prompt rule stopped the claim the same day; days later, real tool use — with a written law: the coach may only say “logged” if the tool was called and returned ok. Advice endpoints stay tool-less on purpose: a weekly summary has no business writing data.

Payoff

The one failure that kills a health product — confident fiction — became structurally impossible. The architecture stopped being a diagram and became the thing that catches the AI when it lies.

Caught by checking the database, not by trusting the reply

04 · Problems met on the way

Living inside your own product is brutal: every shortcut you took finds you within days.

Nobody knows how many grams of oil are in their pad thai

If honest users can’t answer the form, the form is the bug

I trained — and the app said “0 hard sets”

Detecting isn’t preventing — the gate goes where data is written

HTTPS was one command away — and the answer was no

Never promise a notification that can’t leave the building

Nobody knows how many grams of oil are in their pad thai

Natural-language meal logging shipped, and the log stayed empty for three days: the confirmation form asked for five numeric fields no honest person can answer. It became three bulk chips — small, normal, generous — whose translation to grams lives in the engine, never in the AI.

I trained — and the app said “0 hard sets”

RIR was the only field you could skip without noticing, and the only one deciding whether a set counted at all. The detector existed; the gate didn’t. Now the value arrives preselected from the plan, and switching it off warns you what it costs.

HTTPS was one command away — and the answer was no

Without it the phone had no push and no offline. The fix was scripted and ready; its dialog warned that the machine’s name would enter a permanent public certificate log. Privacy won — and the notifications toggle simply doesn’t render where it can’t deliver.

05 · The product

Two surfaces, one engine: training and nutrition, built to work together.

Training

Multi-week challenges and single sessions. Every set logs reps and RIR; double progression picks the next weight.

Nutrition

Meal log over a food library, tracking kcal and macros, with a per-meal day navigator.

Motion proof · 26 seconds, recorded live

Not a prototype. This is the product running.

Home, nutrition, training and progress in one take of the real build. The coach opens with a check-in nudge — a card the engine raised, offered as Accept / Not now. The AI never acts on its own, and Progress reads a 7-day weight average back in plain language.

Home

Where you stand, surfaced calmly

Today's session and the day's macros in one glance. The engine has already done the reading; the screen's job is to stay quiet about it until something matters.

Nutrition

Eating enough is the success state

The day reads against protein, kcal and a fat floor, broken down per meal. Maintenance is the target: a deficit shows up as a warning, never as an achievement.

Training

The rule picks the next weight, not a guess

Multi-week challenges beside single sessions, with a search-and-filter library for breadth without noise. Behind every logged set, the double-progression rule decides what comes next.

Real UI captured from the running app · demo data only (no personal health data)

06 · The system underneath

Brand discipline, applied to product: every token is a decision, documented where it lives.

A semantic token system — colour, radius, spacing and type as CSS variables — under 11 re-themed primitives and 61 domain components. The domain layer grew from 28 to 61 components in a month of real use; the 11 primitives never changed once. The whole palette was then replaced in a one-day rebrand, which is the same fact from the other side.

Token

Light

Dark

--bg

#F8F1EA

#2F2A2E

--text-primary

#322731

#F2ECE4

--accent · fills

#A9614E

#D9A79A

--accent-text

#96594B

#DFAFA2

--primary · CTA

#7C3140

#8E3B4A

--primary-bright

#8E3B4A

#DE93A0

A colour splits the moment fill and text disagree

In the launch palette the brand purple held AA as a button fill (5.37:1) but failed as accent text (3.16:1) — so one colour became two tokens. A month later the whole palette was replaced in a one-day rebrand and the rule outlived it: today's clay ships as --accent for fills (4.7:1) and --accent-text for type (5.5:1). A colour earns each of its uses separately.

Accessibility is a guarantee, not a convention

Focus rings come from one source, and every AA ratio is re-verified by script when a token changes — against the surface it's painted on, not the colour alone.

Scales

Radius: card 16 · pill 24 · input 10
Spacing: 4 · 8 · 12 · 16 · 24 · 32
Type: 11 → 28 px · weights 400 / 600 / 700 / 800

Six spacing steps and six type sizes — small enough to hold in your head, which is what keeps a solo product visually consistent at 10pm.

Two layers · 11 primitives → 61 domain components

Generic primitives (button, card, sheet, dialog…) are re-themed once through the semantic tokens; everything the user actually touches is a named domain component built on top.

07 · How it was built

Designed and built solo, with AI as the development partner, every decision directed by me.

Frontend: React 19 · Vite · TypeScript · PWA (installable, mobile-first)
Design system: Semantic CSS variables · light/dark theme-aware · 11 re-themed primitives under 61 domain components
Backend: Python 3.13 · FastAPI · SQLite
AI coach: Anthropic API (Claude Haiku 4.5) · communicates, never calculates
Alerts: python-telegram-bot · proactive nudges when the engine flags something
Development: Claude Code (Anthropic) · AI-assisted dev, every decision directed by me

Iterative by two-week cycles, and Figma first: every significant interaction as a hi-fi prototype or annotated spec — the session log, the nutrition day navigator, the coach-card dismissal — then build, then live with it for two weeks before starting the next one.

08 · What I would validate next

Shipping solo proves judgment and execution. The next layer is evidence from people who are not me.

Test whether the coach cards feel supportive or intrusive after repeated daily use.

Validate the nutrition language with users who dislike calorie-focused tracking.

Stress-test empty states and missed-day recovery so the product supports lapses without guilt.

09 · What this proves

One person took this from first sketch to a PWA in daily use — no PM, no budget review, no stakeholder approval.
the clearest version of "resourceful self-starter, minimal oversight." The design system and iterative delivery are what made that possible at solo scale.

user · me, by design

surfaces: training + nutrition

engine · no AI in the calculation layer

stakeholders to approve it

All work Get in touch