Skip to main content
JoshuaBriley.
Tools / Calculator

What inconsistency actually costs

Drift never lands on a single invoice, so it stays invisible: a few hours here, a rebuilt component there, adding up across a team and a year to a real annual figure.

  • Five inputs
  • Nothing saved
  • Every assumption shown

Give it five inputs about your team and the rework you live with, and it shows what a structured system is modelled to reclaim, in hours and dollars, every year.

Your numbers

What inconsistency costs you.

Five inputs about your team and the drift you live with. The panel on the right updates as you go. No email, nothing saved.

8

Designers and front-end engineers who touch UI.

3

Distinct apps or surfaces kept in sync.

4.0

Per person: redoing, reconciling, and chasing drift.

$95

Fully-loaded cost per hour, averaged across the team.

How inconsistent today?

Duplicates and one-offs are common

your annual UI debt live

Recoverable per year

$61,560

648 engineer/designer hours/year, reclaimed by structure.

Today's rework cost $139,840
With a structured system $78,280
A structured system is modelled to reclaim 44% of that rework time.

Most teams are surprised it’s a salary, not a rounding error.

Drift never lands on a single invoice, so it stays invisible. A few hours here, a rebuilt component there, a spacing one-off nobody flags. None of it is big enough to argue about on its own. Add it up across a team and a year, though, and it is a salary. The trick to getting a stakeholder to care is putting that scattered cost in one place, as one figure.

That is the whole problem with inconsistency: it never arrives as a line item. It hides inside the work, so it reads like the normal cost of building software rather than a tax you chose to keep paying. The way to make it real is to set your own numbers and watch them land on a single total.

Nothing in there is a guess pulled from the air. Each number in the results panel traces back to an input you set. The point is not the precision of the total. It is watching the small, ignorable scraps of drift compound into a figure large enough that someone with a budget pays attention.

When the number starts to matter

A total is only useful next to a threshold. The estimate scales with two things that tend to grow together: how many people touch the UI, and how many surfaces they have to keep in sync. That is why the curve bends upward instead of climbing steadily.

The cleanest way to read your own figure is to ignore the dollars for a moment and look at the recovered hours. Divide them by forty. That is roughly how many weeks of one person’s time you would get back in a year, and it is the only number you can honestly compare against what building and maintaining a system would cost you. Here is the same formula run at a few common team shapes:

Team shapeRecovered per year
Two people, one surface, an hour a week eachAbout half a week
Six people, two surfacesAbout nine weeks
Twelve people, four surfacesAbout twenty-five weeks
Forty people, eight surfacesRoughly three person-years

At the top of that table, the honest answer is to do nothing. Two people keep a UI consistent by talking to each other, and a couple of thousand dollars of drift a year is cheaper than the overhead of formalising anything. You would spend more building the system than the system gives back.

Somewhere around six to ten people working across more than one surface, talking stops scaling. Nobody can hold every decision in their head anymore, the same button gets built a third time because rebuilding it is faster than finding it, and the recovered figure crosses into the range where a system pays for itself inside a year. Past that it compounds, because every new surface adds reconciliation work on top of an already larger base. That is the real reason enterprise teams end up with design systems and small studios do not: not sophistication, just arithmetic.

Defensible beats dramatic

A number you cannot explain is a number a stakeholder ignores. The moment someone asks “where does that come from” and the answer is a shrug, the whole case evaporates, no matter how big the figure looked. So every assumption behind the estimate is shown: the working weeks, the conservative share of rework a system actually reclaims, the way each extra surface nudges that share up. Nothing is hidden in a black box.

The premise underneath all of it (that drift and rework quietly drain real money, and that structure wins a good chunk of it back) is well-trodden ground. You do not have to take my word for it, and you do not need me to invent statistics to make it sound urgent. The pattern is established. What the calculator does is take that established direction and price it against your team instead of someone else’s.

Put a real number behind it

The estimate is the rough shape, not the verdict. It is meant to start the conversation, not end it. A design system audit replaces the estimate with specifics: which patterns are actually drifting, what each one costs you, and the order to fix them in so the cheapest wins come first.

If you want a faster read before that, the design-system scorecard covers where your system stands today. Either way, you walk in with a number you can defend rather than a feeling you cannot.

Share

Built the way I build production work.

Accessible controls, live state, no framework underneath, and the same tokens as the rest of this site. It should hold up to being inspected as production work. The case studies show the same standard at full product scale.