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.

Sketched on paper, decided in code, read between sets

It started on paper, went through Figma and Claude Design, and then the real decisions moved into code, because a card read standing up with a rest running can only be judged on a phone in a hand. The intake is a chat rather than a form: it asks one thing at a time, accepts “about 180 pounds” or “I don’t know” as answers, and stops as soon as it has what it needs.

The month then reads as one card per movement, carrying its load, its cue, its picture and its stopwatch. Every state was drawn before it was built: the plan generating, a set in progress, a rest running, a month finished. A card never draws blank, because 150+ exercise visuals were drawn in-house and anything outside that library is rejected before it reaches the screen. Hold a card down and it becomes what the chat is about; press its target and the session is under way. It is iOS 26 liquid glass with SwiftUI where only native does it right, the rest timer and the lock-screen Live Activity, in both themes from one token file, and it went to TestFlight testers early so what they actually did in a gym could rewrite it.

OutputThree tabs in React Native with SwiftUI at the edges, 150+ visuals, every state designed, glass in both themes, read one-handed 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, since 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.

Before a build goes out it is run through an AI Security Agent I built for exactly this: a hybrid static and dynamic scanner that reads the code, exercises the live backend and the LLM endpoint, and grades what it finds against the OWASP Web, Mobile and LLM Top 10. Crafted for securing these apps and the way they are developed, it catches around 90% of the potential vulnerabilities, with a code fix and a payload proof beside each one. What comes back is a Markdown report and a content-identical HTML one built on Tailwind, with a sophisticated structure and design: metric cards across the top, severity badges on every finding, per-domain coverage meters, and each finding collapsed to a line until it is opened, so a full audit reads as a page rather than a log.

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 token system first, then 30+ screens on liquid glass

Paper sketches, then Figma and Claude Design, then React 19 and React Native, with a token system for type, colour, spacing and motion set down before the first screen so that 30+ screens would feel like one product and a change would be made once. Liquid glass was a decision, not a default: six graded areas of a life and a daily loop are dense, and glass lets the thing being done sit above the plan it belongs to without hiding it. Friction in that loop was treated as a functional bug, because a habit app only earns its next open if every interaction is effortless.

The assistant was designed as a surface, not bolted on: message cards, a typeface and a tone that keep its answers calm and easy to follow, and a drawn state for every moment in between, from thinking to a failed call. The identity travels with it: transparent-background holograms that rotate on scroll on the web and turn continuously in the app, so the site and the phone are recognisably the same thing. Prototypes went out early and in the open, were validated before implementation, and are now being reworked from what TestFlight users do rather than what they say.

OutputA token system, 30+ screens, an AI conversation surface with every state designed, and a visual identity that holds from the web to the app.

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.

Every release is also passed through a custom-made AI Security Agent, built to secure these applications and their development: it scans the code statically, probes the edge functions and the chat endpoint dynamically, and grades each weakness against the OWASP Web, Mobile and LLM Top 10. It detects around 90% of the potential vulnerabilities and hands back a fix for every one. The output lands twice: as Markdown beside the code, and as a Tailwind-styled HTML report with a sophisticated structure and design elements made for reading, from the metric cards and severity badges down to per-domain coverage meters and collapsible findings, so the state of a release is visible at a glance.

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, and every card with a state

The intake is a chat rather than a form: it asks one thing at a time, accepts “5 foot 6” or “I’m 20 weeks” as answers, works out her week, trimester and BMI itself, and stops as soon as it has what it needs. 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, across four native tabs, in both themes from one token file. It was sketched on paper, worked in Figma and Claude Design, and then prototyped in code, because eleven cards under a thumb can only be judged with a thumb.

The real-world complexity was designed for, not discovered later. A card can never render blank: a missing field gets a placeholder rather than a hole. A red flag is its own state, not a line in the chat: it bypasses the plan for a contact-your-provider callout that outranks the layout, in any week. The assistant answers in message cards, in a typeface and a tone chosen for someone reading at three in the morning, and the same plan exports as a formatted PDF that reads as a document she can hand to a partner or a midwife. Each decision was shared as a prototype before it was built, and TestFlight testers are now the ones deciding what changes next.

OutputEleven cards, four tabs, one token file for both themes, a safety state that outranks the layout, and a PDF that reads as a document.

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.

Each build is checked by an AI Security Agent made for the purpose: a hybrid static and dynamic scanner, carefully crafted for securing these apps and their development, that reads the code, probes the live backend and the assistant endpoint, and grades every finding against the OWASP Web, Mobile and LLM Top 10. It detects around 90% of the potential vulnerabilities, each with a code fix and a proof attached. The findings are written out as Markdown and as an HTML report on Tailwind, given a sophisticated structure and design for a more appealing read: metric cards, severity badges, coverage meters per domain, and findings that fold away until opened, so the audit is something a team can actually look at.

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