I have watched design systems die twice, and both times the cause of death was the same: the system described things the codebase could not build. Not because the engineers were unwilling. Because the values in the file had been chosen by eye, and no amount of goodwill turns a hand-nudged 13px gap into something a spacing scale can express.
So when I built a system for a product with more than one front end and exactly one designer on it, I started with a single constraint, and it did most of the work:
Nothing enters the system unless it can be expressed as a token in the actual codebase. Not approximately. Exactly.
That reads like a limitation on design. In practice it is the opposite.
What the rule actually kills
It does not kill good ideas. It kills a specific and very common category of artefact: the value that exists in one screen and nowhere else.
The one-off gap that is 13px because the designer's eye wanted 13px. The colour that appears in a single card and has no name. The shadow that nobody can reproduce because it was three stacked layers in a Figma effect panel. Each of these is individually harmless and defensible. Collectively they are the reason an engineer stops opening the design file, and once that happens the system is already over.
The rule turns every one of those into a decision you have to make consciously: either this becomes a real token that other screens can use, or it does not exist. Both answers are fine. What is not fine is the third option, which is shipping it and hoping.
Why it works better when you write the code too
I was also the person implementing these screens, which is the part I think actually explains the outcome.
When the designer and the implementer are different people, the constraint has to be enforced socially. Someone has to push back in a review, be the difficult one, spend political capital on a 4px discrepancy. Most people, reasonably, don't.
When they're the same person, enforcement is automatic and slightly humiliating. Every corner I cut on a Tuesday arrived on my own desk the following Tuesday as a bug I had to fix. You learn very fast. It is the tightest feedback loop I have had on my own taste, and I do not think I would have arrived at the same system without it.
The structure worth copying
Three tiers. This part generalises, so it is the part I would actually recommend:
Primitives at the bottom. The raw scales — spacing steps, type sizes, the colour ramp. Nothing references these except the tier above. They are deliberately meaningless: a primitive does not know what it is for.
Semantic roles in the middle, named for the job rather than the appearance.
Not grey-600, but the role that grey is playing. This is the tier that earns
its keep the day someone asks to darken all secondary text, and you change one
value instead of grepping forty screens.
Component tokens at the top, and only where a component genuinely needs to deviate. If this tier is large, the middle tier is wrong.
The mistake I made early was skipping the middle. Primitives wired straight into components feels faster for about three weeks, and then every change is a find-and-replace.
Name things boringly
One more thing, smaller but it mattered more than I expected: a token nobody can guess the name of is a token nobody uses.
I spent a while trying to be precise and ended up with names that were accurate and unguessable. People reinvented values rather than go looking for the right name. The fix was to make naming predictable and slightly dull — if someone can guess the name correctly on the first try without opening the file, the naming is done.
Design systems fail quietly. Nobody announces it. The file just stops being opened, and six months later there are three products that look like cousins. Both of the rules above exist to make that failure loud and early instead.