Dmitry Shishov

A plan read in a gym, not at a desk

The exercises are not the missing piece. Every workout builder already has them, SimplyFitness’s among them. What they leave to the user is the assembly: the split, the movements, every set, rep and load, again and again for each session of the month, slow and entirely manual, and all of it learnt before the app gives anything back. Gymmate does that work instead: a few questions in a chat, then a personalised month that can be changed by saying so in a message. And it belongs on a phone, because the plan is read one set at a time, standing up, with a rest running.

OutputThe manual half of a workout app handed to an assistant, and safety rules that outrank the prompt: never diagnose, never through an injury instead of around it, never a load their numbers don’t support.

A coach’s questions, then one card at a time

The intake is still a chat that asks one thing at a time and pulls the values out of what they say, because “about 180 pounds” and “I can bench my bodyweight” are answers a set of number inputs would have rejected. “I don’t know” starts that group at Novice and gets calibrated in week one, and what is still missing is decided server-side, so the interview ends when that list is empty. The month then reads as a card per movement, carrying its load, its cue, its picture and its stopwatch. Hold one down and it becomes what the chat is about; press its target and the session is under way, in iOS liquid glass, in either theme.

OutputThree tabs in React Native, glass throughout, read one-handed between sets in a noisy gym.

TypeScript on the phone, Python where the numbers are

Expo, React Native, React 19 and Zustand on the phone; a FastAPI backend behind it where every call to Claude goes through one module and the key never reaches the device. Plans come back as structured objects: the shape is a tool schema and the call is forced with tool_choice, so what arrives is already validated, with no JSON to parse, and each key renders straight to a card. The model never sees the whole exercise library either: a local filter puts only what this person can lift in front of it, so a prescribed movement is one it was shown, and a name outside the library is rejected server-side rather than drawn as a blank tile.

The arithmetic stays in Python: BMI, one-rep-max estimates, the five-level banding, every date in the four weeks. The static half of the system prompt is cached; Haiku throughout, since every call happens while they wait. The rest timer is SwiftUI written from TypeScript: two dates go up once and iOS draws the count while the phone sleeps.

OutputRoughly 7,800 lines of TypeScript over 7,100 of Python: validated structured output, a closed library, cached prompts, and native work where only native does.

Changes in their own words, and an account behind them

Refinement happens in plain language: a routing tool turns “swap the deadlifts for something my back can handle” into an edit of the card they are holding, rewritten against that card’s own schema, so a misread request is one wrong card, never a rewritten month. Said out loud it needs no app: a Control Center button records through a locked screen — the rest card there is what lets it hold the microphone — and the same assistant starts the exercise, runs the rest, answers anything about the gym, their level or the plan, and reads it back. On screen it streams over SSE, cites its form notes and finds a video by search, every link checked. Accounts came with it: Supabase behind the same backend, the anon key stays there, their token goes up, and row-level security picks the row.

OutputNatural-language editing spoken or typed, grounded links, a month that still goes in a gym bag, and one row nobody else’s token can reach.

Metered, tracked, and on TestFlight

A card starts when its target is pressed and is spent when the rest has run its whole length once per set, so what they actually did is recorded beside what was prescribed. A week before the month runs out the app asks five direct questions, and the next one is written from the answers rather than from the interview again. Every call is billed by the token, so an account gets five dollars a month and a phone with no account a dollar, counted in a ledger that can only be added to.

The backend ships as a Docker image, the app builds through EAS, and every decision above lives beside the code.

Defining what an AI habit companion actually has to do

An idea on paper. No product, no code, no interface. The first job was turning that concept into a defined product: what does an AI habit companion actually do that a notes app or a generic chatbot can’t? The answer shaped everything. It has to know the user’s real state, and it has to act on their plan rather than describe good intentions. I mapped the core loop (capture, plan, do, reflect) and decided early that the AI would be an applied system, not a chat box bolted onto an app.

OutputA clear product definition, a prioritized feature set, and the architectural constraint that drove every later decision.

A liquid-glass design system across 30+ screens

Built the interface around iOS’s liquid glass design language, with a Figma token system carrying type, color, spacing and motion consistently across 30+ screens. Intuitive design was treated as core engineering work here, not decoration. A habit app only earns repeat use if every interaction feels effortless, so friction in the daily loop was a functional bug, not a polish item.

OutputA complete, consistent design system and screen set validated before implementation.

The grounded, tool-using AI layer at the heart of the product

The heart of the product. Users talk to it by voice through OpenAI Whisper or by text, and a custom context-engineering layer assembles every request from their live profile, habits and progress, so the model reasons over grounded current state rather than generic advice. A system prompt shapes tone, structure and what the assistant is allowed to advise. Because that context grows with the user, I built context-window management and token accounting into the pipeline to keep cost and latency predictable.

On top sits a streaming Claude integration with tool use, giving the model defined operations to read and modify scheduled activities and the long-term plan, so the assistant acts on the app’s data instead of just talking about it. Web search extends that reach outward, surfacing a relevant video or academic paper when a goal calls for it.

OutputAn AI layer that is grounded, capable of taking action, and economically viable at scale.

React Native and Supabase wired around the inference layer

React Native, Expo, React 19 and Zustand on the frontend, wired to the design tokens. A complete Supabase backend behind it: PostgreSQL with row-level security, auth, 9 Deno edge functions acting as a secure inference and orchestration layer, and timezone-aware push notifications so reminders land at the right moment wherever the user is. Roughly 20,000 lines of TypeScript in total.

OutputA fully featured product with the inference layer kept server-side and secure.

Live in TestFlight beta, structured for a growing team

Shipped to beta on TestFlight, where real users now run the daily loop against real data. The codebase and design system were structured for handoff from the start, and the team is currently expanding around it: a live iOS app in beta, plus a foundation another developer can pick up and extend.

What the app must do, and what it must never do

Two halves, decided together. What it must do: turn one short conversation into a plan for the trimester and the week she is actually in, covering nutrition, symptoms, her baby and the appointments due now, that she can change by asking, and derive her week, trimester and BMI rather than ask for them, because no one knows their own day count. And it belongs on a phone, which is where a plan for a week is actually read. What it must never do: diagnose, touch a medication, comment on her weight. Red flags bypass guidance for a contact-your-provider callout, in any week.

OutputA product definition in two halves: an intake reduced to what only she can answer, and safety rules that outrank the prompt.

A conversation instead of a form, a phone screen instead of a page

The intake is a chat that asks one thing at a time and pulls the values out of what she says, because “5 foot 6” and “I’m 20 weeks” are answers a set of number inputs would have rejected. What is still missing is decided server-side, so the interview ends when that list is empty. The plan is then eleven cards she thumbs through — nutrition, symptoms, her baby with visuals, the visits to book — drawn on iOS 26’s own glass.

OutputOne token file carrying both themes, and four native tabs.

A phone in TypeScript, a model graph in Python

Expo, React Native, React 19 and Zustand on the phone; a FastAPI backend behind it where every call to the model goes through one module and the key never reaches the device. Both plans come back as structured objects: the shape is a tool schema and the call is forced with tool_choice, so what arrives is already validated, with no JSON to parse, and each key is one card. Strict mode is off deliberately: it fills a blank field with a placeholder rather than leaving it out.

The weekly plan is a LangGraph state machine rather than a chain: search first, then a conditional edge that forces the schema once the results are in context. Streaming is reserved for the one thing still prose, the assistant, over SSE.

OutputRoughly 5,300 lines of TypeScript over 3,300 of Python: LangChain on gpt-5.6-luna, validated structured output throughout.

Tools outside the model, and an account

The week links a real article, so the model is never allowed to write a URL from memory: a hosted search is locked to one domain and the plan cites what came back. Changes happen in her own words: a routing tool turns “swap the lentils” into an edit of one card, rewritten against that card’s own schema. Accounts came with the phone: Supabase fronted by the same backend, so the anon key never ships in the binary, and row-level security picks the row.

OutputGrounded links, natural-language editing, and a plan kept in a single row that nobody else’s token can reach.

Current on her phone, and shipped from two places

Her copy is the one that lasts: the whole plan sits on the phone and is handed back to a restarted server under the same id, regenerating nothing. Her week is counted again from her dates every time she opens it, so what the calendar has moved past is fetched again, the trimester band with it. Any card can be double-tapped to sit above the chat about it.

The backend ships as a Docker image, the app builds through EAS, and every decision lives beside the code.