A 500-recipe catalog, every step narrated, every image generated, designed and built and produced by one person in five months, feature-complete for launch.

Voice is the thesis, and the hard part was not recognition. It was deciding when the app is allowed to listen, and being honest about it. The microphone opens only in the gaps between narration, because while narration plays the app would hear itself. The pill reads red while Growl speaks and green when it is listening.

The pushback. When per-step video shipped, should "play video" work during narration? Letting one command through the closed mic window was technically clean and failed on honesty: an affordance nobody can see is not an affordance, and a pill reading red while secretly accepting a command makes the pill a lie. The tap stayed; voice stayed for the hands-free moment it was built for.

A recipe was either video, every step a clip, or audio, every step a still. That forced one answer for all eighteen steps of a dish where three need motion and fifteen do not. The test was always whether watching teaches something the narration cannot, and that is a question about a step. The catalog went from 617 clips to 77. The Watch & Cook browse surface was deleted in the same change.

The cost score informs the format and never decides it. The hardest steps to generate, pleating, rolling, forming, are the ones a cook most needs to see.

An early scoring script ranked recipes by how well they would render, and nothing weighed demand against it. Measured later: 50 soups and 2 salads out of 173 recipes. Every step of that reasoning was sound and the outcome was nobody's plan. Fifty more recipes went in and nothing moved; the redistribution was a deliberate act at a specific moment, not drift. The fix was structural: which dishes is answered by demand, what a US home cook makes on a Tuesday, and which format by whether motion teaches. Soup & Stew went from 29% to 14% of the catalog, not the 11% projected, because soups kept being added. Seafood went 3 to 27, Salad 2 to 15. Sushi went 2 to 3, because an empty category is not automatically worth filling.

Every image and clip in Growl is generated. The pipeline is 106 scripts across thirteen steps, from sourcing a recipe against three references to the final audit. Not a single defect reviewed contradicted its prompt. Every one filled a silence, so the test on a finished prompt is not "is this accurate?" but "what would a stranger have to guess at?"

What I didn't build. Knives in motion. Three waves failed; cuts are two stills joined by a hard cut, at a third of the cost. Allergen filters. "Nut-free" is drawn in Figma and deliberately unimplemented, because a free-from claim being wrong can hospitalize someone, and the claim covers the whole dish. "Contains nuts" asserts nothing; "Nut-free" asserts everything.

CLAUDE.md is the project's memory: 2,018 lines and 36,512 words of rules, each tied to the failure that produced it. Figma is the single source of truth with three rules: never invent a value, 1:1 parity, build only what is marked Ready for Dev. Six parallel agents authored the final 542 image descriptions from one brief; all 41 contact sheets were then reviewed by eye. That found six defects the automated check passed. The numbers said 583 of 583 succeeded. A clean automated check is not a pass.

Drag to compare. Cast Iron Ribeye, as designed and as shipped. Drag the divider to compare, drag anywhere else to pan, zoom with the control or ⌘ scroll, double-click to reset. The node reference under the slider is the Figma ID the SwiftUI file cites.

Stripped Figma file: tokens, components, Ready for Dev markers, and one logged divergence that owes Figma a correction.

Calm's first new consumer app in twelve years shipped on the foundation in four months, Android followed about six weeks later from the same system, and Calm Health adopted it for a product that had not shipped yet, without a mandate.

Two tiers is the common setup and faster to author. The extra indirection cost authoring time up front and bought the ability to re-theme a whole vertical, light and dark included, without touching a component. Interaction states work the same way: a component picks a role, and the system resolves default, hover, active and disabled.

The one I re-spent. At Calm, disabled states resolved as a primitive at 40% opacity instead of carrying their own value. It halved the accent group and read correctly on every flat surface shipped, but a disabled control inside a dimmed container landed at 16%, and nothing in the system prevented it. The reconstruction spends the tokens: accent/accent-disabled and text/disabled are values, and the states figure below uses them.

Nothing inside the card changes between verticals. Pick a brand and a mode; every value resolves through a semantic token to a primitive, and the trace shows the path. Tokens are from my export of the system, resolved exactly as the file resolves them.

A reviewer should be able to open the system, not take my word for it. Everything below runs on the Foundation token set, three collections and five brand modes, checked against the shipped Sleep screens. Three values differ from the file on purpose and are logged in the decision table: dark labels on the Parenting and Fitness accents, a label token for secondary buttons, and a tonal secondary in dark mode. Filter the semantics, switch brands and modes, check the states and the contrast.

How it reaches code, on both platforms. The system shipped to iOS and Android from one source. Every variable carries three names, CSS, Swift and Kotlin, so the token a designer sees in Figma is the identifier an engineer types. On iOS the semantics resolve through a Foundation theme object; on Android a FoundationTheme wraps MaterialTheme and maps the color scheme onto the semantics, so stock Material components take the brand without being rewritten. Sizes and spacing export as points and dp from the same numbers. I designed directly in SwiftUI and Jetpack Compose with the iOS and Android engineers reviewing the builds; Android followed Sleep's iOS launch about six weeks later, from the same system with no separate library. For Calm Health, Spencer S., their lead product designer and the person I met with weekly, ran the token export to code and handed it to their engineers himself, on the process I had walked him through: the system was theirs to operate before their product shipped.

A system that is not accessible at the token level cannot be made accessible per screen. Foundation treats Dynamic Type, touch targets, contrast, focus and reduced motion as properties of the system, so a screen built from it inherits them without a designer remembering.

Calm is a product you feel more than read. The signature animations shipped: Breathe Bubbles and the check-in, designed in Rive with the motion designer, then rebuilt in Swift when the Rive runtime did not hold up on device. What did not ship was the system underneath them: motion tokenized in the same three tiers as color, so a check-in, a sheet and a breath would move with one vocabulary across Sleep and Health. Those values were defined and available to engineering before I left; Calm treated applying them as a refinement stage after launch, and I left before that stage came for any app. What is below is the system as I built it, with the values reconstructed here rather than copied from a build, and the two shipped animations beside it.

A system without governance is a library that drifts. Foundation shipped with a contract for builders, a lint that enforced it, and a log of decisions, including the ones made against design. Rules are easy to write. These three are the ones that operated.

A system is proven by a screen, not a token list. These are the Discover screens I built in the Foundation file, one per brand, from the same components: the search field, the category tiles, the Content Hero Card with its Chip, the Button and the Tab bar. Switching the brand mode re-themed them; nothing inside a component was touched. The accents are the brand tokens: blue/600, peach/600, amber/600. Sleep's blue shipped; the Parenting, Fitness and Health accents were proof-of-concept values to exercise the brand tier, not palettes chosen for those apps. Fitness's white label on amber is the pair the audit flagged; the system now resolves it to black. Rebuilding the composition for this page surfaced one fix: the hero card's text was bound to accent-on, which turns navy on Classic, so text over artwork got its own semantic, text/on-media.

Without a mandate, the system needed a product to ship inside. Classic had been captured, with engineering, as the foundation's first brand; Calm Sleep had no legacy to protect and I was designing it from zero, so it ran on the new foundation from the first screen as its second. It did not slow the launch. It sped me up: fewer decisions per screen and no rebuilding patterns that already existed.

The foundation also kept paying after launch. The MVP plan card was a surface with the artwork inset and the text below it, built fast to ship. Once Foundation's Content Hero Card existed, I replaced it: full-bleed artwork, the adaptive scrim, the category as a chip, the title over the image, a single play affordance. Same data, same slot in the plan, a component swap rather than a redesign. That is what a system is for after the launch, not just before it.

Pushback. Contrast could not be guaranteed over artwork that changes every session, so the MVP kept text off the image. I pushed for full-bleed cards and engineering built a scrim that adapts to the image at runtime. It went back into the foundation, so every product on the system inherited it.

Buy-in was thin where I needed it most and strong where I had not expected it. I took the system to other teams directly. Calm Health, on the Enterprise side, adopted it while their product was still being built and met with me weekly for three to four months to learn it and push it further. I built Health's brand tier with them, ten overrides on the accent family and nothing else, and taught the mechanics: aliasing, how modes resolve against a component, how to build component properties so collection theming holds. They left able to extend it without me. They never pushed back on the system itself; they embraced the working relationship. The one worry they voiced was about time, not structure: with AI moving as fast as it was, would what I was teaching still hold a year on, and would the way we were structuring things still be the right way. It is a fair question for any system built in 2025, and the answer I gave is the one this page makes: tiers, named intent and tokens that carry their own rules are what an agent can read, which makes them more durable as AI advances, not less. Their product had not shipped when I left, so this page shows the brand file rather than screens.

What Health pushed back on. Nothing in the system. The one worry they voiced was about time: whether what I was teaching would still be the right structure a year on, with AI moving as fast as it was. The answer is the one this page makes, that tiers and named intent are what an agent can read, so they age well.

Classic was captured, not migrated. With engineering I encoded Calm Classic's primitives, semantics and brand into the foundation, so its twelve years of UI resolved from the same tokens, dark mode included. Moving Classic's screens onto the new components was never prioritized by DTC. The system holds Classic; the product still runs its old code.

Twice. At Calm, Claude drafted the token structure and naming conventions and I set the boundaries: what belongs in a primitive, what is a semantic, what only a brand may know. Then I showed Health's team the same loop, feeding the token structure and a component into Claude and getting screens back already speaking the system's language.

And again for this page, as a test. In October 2026 I had Claude, working through Figma's MCP, rebuild the system from my token export and 290 shipped screens, 103 from Sleep and 187 from Classic, without access to the Foundation file: three collections in my naming, every component fill and stroke bound to a semantic, a composed screen flipped across the brand modes. Then I compared it to the Foundation tokens. The shipped accent sampled at #2b6cfa against blue-600 #2a6dfa; the tier structure, the ten brand overrides and the semantic set matched; the reconstruction missed the Health purples and the elevation ladder, which only the file had. The method is the same one the system was built with: AI drafts, I decide, the product confirms.

Calm's first new product in twelve years launched on iOS in four months, with a 4.7 rating and install-to-paid above target in both markets.

The targets were met. Then the numbers turned, for the two reasons design had argued about before launch: users found they had no control over their plan, and recognized the content as Classic's. The app did not differentiate itself enough, and the main app lost users to it.

Calm Sleep had good content and no way in. Browsing assumes you know what you need, which at 11pm nobody does. The plan is a curated set of tasks tied to each user's onboarding answers, with a Sleep Readiness score that makes progress visible. Every item maps to one of nine scientific foundations, so personalization is grounded in sleep science, not preference.

Early testing showed users understood what the plan was for but not how it worked. What counted toward Sleep Readiness was not clear. The tempting move was more personalization. I prioritized making the scoring immediately legible, because tuning a system users do not trust yet only compounds the problem. The first round, moderated sessions on the mid-fidelity prototype, returned three things to fix: make the plan mechanics immediately clear, reduce the cognitive load so the screen reads as a plan rather than a checklist, and personalize the activities to the sleep problems people named.

Users described the tasks as short and manageable, but the screen still read as a checklist. The fix was not fewer or shorter tasks. It was tightening the surface itself: the difference between "here is your plan" and "here is everything you could do." The second round confirmed the plan was understood and the tasks felt short and manageable, with consistency still hard on busy days. Two asks came out of it: clearer guideposts on what matters most, and the right balance of repetition and variety.

Pushback. Testing reshaped priorities twice before launch. The second instance was the ask for guideposts: it became the ordering of the plan, the item on the strongest foundation first, with the readiness milestones saying why. I argued against adding a difficulty label per item and won; the label would have reintroduced the checklist feel the round had just removed.

The progressive player. A guided, sequential content experience aimed at the two drop-off points in the data: tonight's items queued in order, the week visible above. Explored and tested, never shipped. It is the version I would build next.

This page has no generative AI in it, and says so. The personalization is designed logic: onboarding answers flag foundations; each foundation owns a pool of plan items; a day's plan is three items drawn across the flagged foundations, with the sleep-wake schedule as the anchor. Sleep Readiness is a count, three of three, resolved by rules I could explain on a whiteboard, not a model. I owned the mapping and the item taxonomy; engineering owned the engine. For a reader at an AI company the point is the sequence: legibility, then trust, then personalization. The same sequence applies to any system that adapts to a person.

Task success rose on every tested task. Free-to-paid conversion rose 5.25% and paid churn fell from 7% to 5% in the first month after launch.

Users' three questions were answered in two places. Linking Reports and Scores would have been the easier fix. I consolidated the content into one Credit tab, organized around the questions users asked rather than how the data was stored, and kept the full report one tap away.

Users needed to compare Experian, Equifax and TransUnion, and the old experience made each one a separate trip. A sticky bureau switcher lets them compare without leaving the view. Comparing went from 19% to 89% task success, and users named it one of the most valuable parts of the redesign.

I broke the MVP into three phases with product and engineering, sequenced by how each section relates to the others and by effort. The score came first because everything else explains it or acts on it. Each release went through usability testing before the next, so feedback shaped the product while it was still being built.

Pushback. I pushed for contextual education in the MVP and lost to scope: product held the MVP to the three questions and the education came after. So I built the IA to accept it later. Industry-specific FICO scores stayed at 55% success when every other task cleared 70%.

Contextual education, in the MVP. An education slot: a prompt, a two-line answer, one link deeper, placed inside the section that raised the question. Designed, argued for, cut from the MVP; the IA held the slot. After launch I built it: an educational carousel of the questions new members ask, and an education screen, Tips for a good score. Two more, discussed and never built: a settings experience that let users control what CreditHub showed them; and richer infographics for the content, which the rules on how score information may be represented did not allow.

None. This work predates the pipeline, and the page says so in one line rather than retrofitting a story. What carries forward is the method: test between every release, and sequence by what explains what.