Out of design artifacts and into code: the two largest design systems I've worked on rebuilt as real front-ends, prototypes running on them, and a product idea built from scratch.
Into code. I've rebuilt the two largest design systems I've worked on as real front-end code: the same two that were design artifacts on 18 September. 115 React components between them, each with a token source that compiles to CSS variables rather than sitting as a flat file, and four brands themed light and dark on one of them. Both built out from my own design files rather than from anyone's codebase.
Storybook as the test harness. 111 stories across the two, and every one runs as a test in a real browser. Break a component and the run fails, rather than waiting for someone to notice. Brand, theme and direction all switch from the toolbar, so any component can be checked in any of the ten theme combinations, LTR or RTL, without leaving the page. Everything in this log up to now lived in design artifacts; this is the first version an engineer could open, read and argue with.
Docs from the same source. Both documentation sites import the same components and tokens the products use, so each system has one source feeding the docs, Storybook and the apps. Every design system I've worked on had documentation that lagged the components by a few days or weeks. These structurally can't.
Also
- Several app prototypes covering different user types and journeys, built in Claude Code from the system's own components rather than drawn. Starting a new one is now an afternoon, because the parts underneath are real
- A product idea I'd shared with a former colleague, written down as a vision and then actually built on Chakra rather than a component library from scratch, because the question was whether the idea worked, not whether I could make buttons. Two weeks ago it would have stayed a conversation
- Accessibility violations report per story in Storybook, checked as you build rather than audited at the end
Not yet. No backend. There's a sign-in screen, but nothing behind it checks anything. No data layer worth the name. These are front-ends: real components, real tokens, real states, nothing behind them. Worth saying plainly, because "I built a product" can mean very different things.
Every design system I've worked on had documentation that lagged the components by a few days or weeks. These structurally can't.
Next. Two things I know are missing.
- Versioning: no releases, no changelog, nothing for anyone to pin to. Fine for one person, untenable the moment a second team builds on it
- Visual regression, properly or not at all: scaffolded and unused, so either wire it up or take it out
After those, the questions that need other people in the room: where governance sits, what stops drift, and what a review looks like when the thing being reviewed took ten minutes to make.