One extra button can become one more review, one more accessibility fix, and one more upgrade to coordinate. Across products, the repeated work becomes harder to see—and harder to plan for.
A local variation may solve a real need. The question is whether the team understands the maintenance that comes with it. This article identifies where that effort shows up and how to bring concrete evidence to a planning conversation.
Where the costs show up
Most teams treat component drift as a design-system problem, but it behaves more like 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, but it makes every review a little slower.
Accessibility bugs multiply
Each fix has to be repeated in every copy of the component. 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, or a faster way to render, but it only reaches teams already using the shared version, while 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
These costs aren’t hidden so much as spread out. Review friction looks like slower delivery. Accessibility debt looks like a cleanup sprint. Designer time looks like design “can’t keep up.” New hires spend time checking which patterns they can reuse. Each one has its own explanation, and none of those explanations point back to the real cause.
These costs are easy to track separately. The cost is real, but there’s no line on any spreadsheet called component inconsistency, so nothing ever gets charged to it directly.
Repeated UI work is easier to discuss when you can show where it happens.
Measuring the cost
The first step is measurement rather than a big rewrite: a way to turn this scattered cost into a number that can sit next to the features competing for the same budget.
Start with one pattern across a small set of products:
- Inventory the versions in use. Find the shared component, local copies, and intentional exceptions. Record who owns each one and why it exists.
- Compare behavior as well as appearance. Check keyboard interaction, errors, loading, and responsive states. A matching screenshot can hide different maintenance needs.
- Connect the differences to real work. Review recent tickets and pull requests. Record repeated fixes, review questions, and upgrade effort. Use ranges when time records are incomplete.
The Design System Scorecard is a self-assessment for discussing system health. The UI rework calculator models an estimate from your inputs. Neither scans your codebase or replaces a component inventory; use them to organize a conversation around the evidence you collect.
How to start
Choose one frequently used component and inspect it in code, design files, and a few live product states. Ask its maintainers which differences are intentional and which create repeated work.
Bring those examples to the next planning conversation. Propose a focused change with an owner, a migration path, and a way to check whether the repeated work decreases. A useful baseline does more for that decision than a count of buttons on its own.