Consistency Dies at Adoption, Not Creation
I audited my own design system expecting a museum of small inconsistencies. The real debt was two things I wasn't looking for: hardcoded colors breaking the token contract, and consumers drifting a version at a time.
I expected the audit to be embarrassing.
eidotter is my design system — a DOS-themed component library with a CGA palette, under the interactive parts, and design tokens exported as and a Tailwind preset. Around 48 components. More than a dozen of my own projects pull it in. I built it in the gaps between other work, and I assumed that meant it had drifted — that if I lined every component up against a strict checklist, I'd find a museum of small inconsistencies.
So I built the checklist. Eight dimensions per component: accessibility, keyboard support, token usage, feedback states, perceivability, light and dark modes, motion, and restraint. Then I went through all 48, one at a time, scoring each.
The result wasn't what I expected.
The system was structurally strong exactly where I thought it might be weak. Accessibility held up. React Aria was doing its job. Motion was disciplined. On seven of the eight dimensions, most components passed. There was exactly one systemic failure, and it ran through everything: token discipline.
Hardcoded colors. Not everywhere, but scattered — a literal hex dropped inline instead of referencing a token. Individually they render fine. Collectively they were a wall. Every hardcoded color was a value that couldn't be remapped, and a whole second theme — a light mode that remaps the CGA palette to AA-compliant values instead of abandoning it — was silently blocked by them. The components looked consistent. The contract underneath them wasn't.
That's the trap with tokens. A component drifts at the token layer first, and nothing else catches it. A hardcoded color passes every visual review, every screenshot diff, every "does it look right" — it only fails the moment you try to change the thing it should have deferred. Tokens are the contract. A component that inlines a value has quietly broken that contract while still looking completely correct.
The system wasn't inconsistent. It was under-tokenized.
Then I audited the other side — the dozen projects that consume eidotter. This is where I expected the real inconsistency, and I found it, but not the kind I was looking for. The debt wasn't components disagreeing with each other. It was version lag: projects pinned to older releases, each frozen at whatever the system looked like the day they adopted it. And worse, local duplication. A project that needed a token its installed version didn't have would just copy it in — redefine the color, fork the component, move on.
Consistency doesn't die at creation. It dies at adoption.
A system can be perfect the day you ship it and still fragment across its consumers, because every project that lags a version or copies a token locally is a small secession. The canonical source stops being canonical the moment a consumer stops tracking it. I'd spent months worrying about consistency inside the system and almost none on the thing that actually determines it: whether the projects using it stay current.
Which turns out to be a governance problem, not a design one. The instinct, when you find drift, is to add gates — a stricter contribution process, a review step, a checklist to clear before anyone can change anything. The counterargument that stuck with me comes from : heavy contribution gates drive away exactly the contributors a system needs. Quality follows ownership. If updating the system is painful, people route around it — they copy the token locally, and now you have the fragmentation the gates were supposed to prevent. The number worth tracking isn't a consistency score; it's whether staying current is the cheapest path a consumer has.
There's a business case for all of this that I'm slightly allergic to but that isn't wrong. puts numbers on it. But for a portfolio of one person's projects, the return isn't measured in QA hours saved. It's measured in whether I can change the amber once and have every project follow — which lands right back on tokens and adoption, the two things the audit actually flagged.
So the audit inverted my assumptions. I went in braced for a system I'd built in a hurry to be riddled with inconsistency, and instead found one that was structurally sound but under-tokenized, feeding a dozen consumers that were drifting because staying current cost more than copying. The lesson isn't "write more components" or "add more rules." It's narrower: guard the token layer above everything else, because that's where drift hides in plain sight — and treat consistency as an adoption problem, because that's where it's actually decided. Everything else is downstream of those two.