A design system that ships to production, not to Figma
Most design systems are Figma libraries; engineers copy the values into their own platforms by hand. I built a deployed service instead: a Git repo, Style Dictionary, and automated sync, so a token change updates every consuming platform in seconds. Figma is one consumer, not the source.
The problem
Change the radius on a card at Bibel TV, and that isn't a five-minute edit. Development sits with an external agency, so it's an estimate in hours and a slot in a sprint. Small changes were not small.
That cost existed because each of the four platforms — iOS, Android, web, connected TV — kept its own copy of every design decision: Kotlin values, Swift constants, CSS variables, Figma styles. Change a color in one place and four teams had to catch it in four others. In practice, three fell behind every time, and the platforms drifted apart. The design system was a Figma library people referenced, with nothing enforcing that the reference stayed true.
There was also a budget reality underneath all of it: no platform-engineering team to own design infrastructure. If the Head of Design didn't build it, nobody would.
The architecture
The other options each failed somewhere. A Figma-only library breaks at scale through copy-paste drift. Per-platform token sets give flexibility but make every change an N-times job. A Storybook system handles web and ignores native. Manual sync holds only as long as one person stays perfectly consistent.
View full size ↗ Android, web and Figma read the same build today. iOS and connected TV are dashed: reaching them is an implementation task, not a system change.
Read the reasoning behind this decision
What I built is a Git-based token repository that builds to a live API the platforms consume directly.
One Git repo holds the tokens, versioned and reviewed like any other code. A four-tier hierarchy keeps them sane, running from primitives (OKLCH colors, spacing, type) through semantic and component to the page and view tokens a product team works in. Style Dictionary builds platform-specific outputs from that single definition. An automation layer distributes every committed change to the platform endpoints and the Figma plugin.
The top two tiers are the part a purist would question. Component and page-or-view tokens introduce no new values at all; they alias downward to semantic and primitives. That redundancy is deliberate. Each is a place the company can reach in and change a component's spacing or type size, or border radius across the board, without going through the agency that owns the code. Read as a taxonomy it is redundant. Read as a control surface it is the whole point, and it is the first step toward server-driven UI for the streaming section of the app.
The agency backed it, which I did not take for granted. The architecture takes billable change work away from them and they were enthusiastic anyway.
What changed
View full size ↗ Figma as a consumer, not the source: the plugin pulls the primitives from the token API into the design file, and every component page binds to them.
View full size ↗ One token, two platforms. The shipped Android app loads this payload at launch, and Storybook reads the live token API. On both, the primary button's fill and label match the token to the hex, in light and in dark.
- Sync
- Four teams hand-updating tokens; platforms drifting apart One commit in the token repo, and every consuming platform updates without anyone touching code
- Reach
- A platform-agnostic token API: Android, web and Figma already build on it, and reaching iOS or connected TV is an implementation task, not a system change
- Structure
- Four-tier token hierarchy: consistency enforced by structure, not by coordination
Want to hear more?
- Want to know how I got the agency that bills for every UI tweak to back a system built to make most of those tweaks free, or why two of the four token tiers were built to add nothing at all?