Every team I’ve worked with tells the same story. Someone needs a button. The one in the design system doesn’t quite fit, so they build a new one. It makes sense at the time. It always does. Multiply that by two years and six teams, and you get a problem nobody meant to create and nobody owns.
Component inconsistency rarely causes one big, visible failure. Instead it’s a small cost that repeats in a dozen places, and no single place owns it. Because it never shows up as one ticket, it’s hard to point to. But once you start looking, you’ll find it everywhere.
This post names the specific places that cost hides, so you have something concrete to bring to a planning conversation instead of just a hunch.
The hardest bugs to fix are the ones that don’t look like bugs. They look like the way things are.
Where the cost actually lives
Most teams treat component drift as a design-system problem. It isn’t. It’s an accounting problem. The cost is real, but it’s split across several budgets, and no single budget feels enough of it to act.
Here’s where it usually hides:
Slower code reviews
Reviewers pause to ask which version is the official one. It doesn’t block the pull request. It just makes every one a little slower, forever.
Accessibility bugs multiply
One fix stops being one fix. You end up patching the same problem in four codebases, and hoping you caught all four.
Designers answer the same questions
“Is this spacing right?” “Is this the new card or the old one?” Small questions like these get asked, and answered, over and over in meetings and chat threads.
New hires relearn everything
New engineers learn the patterns in one part of the codebase, then find out those patterns don’t apply anywhere else. So they ask around, or just build their own version.
Upgrades only reach part of the product
You ship a better focus state, a cleaner token, a faster way to render. It only reaches the teams already using the shared version. The rest stay on the old one. Over time it gets harder to justify investing in the shared system, because fewer teams actually benefit from it.
Why leadership can’t see it
None of these costs are hidden. They’re just spread out. Review friction looks like slower delivery. Accessibility debt looks like a cleanup sprint. Designer time looks like design “can’t keep up.” Onboarding problems show up in exit interviews. Each one has its own explanation, and none of those explanations point back to the real cause.
Nobody adds these costs together. The cost is real, but there’s no line on any spreadsheet called component inconsistency, so nothing ever gets charged to it directly.
Costs you can’t name never get budgeted. Costs you can name become the next planning conversation.
Put a number on it
The fix for an accounting problem isn’t a big rewrite. It’s a way to measure the problem. Something that turns this scattered cost into a number, so it can sit next to the features it’s competing with for budget.
I call mine a Design System Scorecard. It’s simple on purpose. It does three things:
- Counts what exists. How many different buttons are actually in use across your products? How many date pickers? The number is usually higher than anyone expects, including leadership. That surprise is useful.
- Measures how far each one has drifted. For each component, how different is each version from the official one? A rough scale is enough. You don’t need precision, just a number.
- Adds up the maintenance cost. Look at the last two or three quarters of tickets tied to these components: hours spent, bugs filed, accessibility issues found. Put it on one page.
None of this is new or clever. The value is in writing down a number for something that’s only ever been a feeling. A feeling doesn’t win budget arguments. A number does.
What to do on Monday
If you want to start, don’t write a proposal first. Open the code and the Figma file, and count buttons. Just buttons. Give it one afternoon.
Two things will happen. The number will be bigger than you expected. And once you’ve seen it, you won’t forget it, and neither will anyone you show it to. That’s when this stops being an abstract concern and becomes a real conversation, and real conversations are how design systems get funded.
This cost isn’t hidden because it’s small. It’s hidden because nobody has named it yet. Naming it is the whole job.