The case for a design system is real, and smaller than the slides say
Two controlled studies are quoted more than any others. In Figma's study, designers finished a task in 34% less time when they had an up-to-date design system (Figma, 2019). Figma did not publish how many designers took part, and calls the figure the maximum a team should expect in real work.
In Sparkbox's study, eight developers built one contact form in a median of 2 hours with IBM's Carbon design system, against 4.2 hours from scratch (Sparkbox). The authors call it "a small study of a handful of excellent developers". The order was fixed, and two of the from-scratch builds were more accessible than their Carbon versions.
These are honest studies of single tasks. We looked for an independent study that measures the return of a design system across a whole organisation over time, and found none. The most transparent published model prints its formula, lists its assumptions and suggests reporting about ±25% around any result (Speicher and Baena Wehrmann, Smashing Magazine, 2022). The calculator below follows the same approach.
The return of a design system is not a number you can borrow. It is a number you measure in your own organisation.
Three costs rarely appear in the budget
Drift is work done twice. A designer detaches a component to meet a deadline. An engineer rebuilds a dialog that already exists. An agent copies the nearest example instead of the system. Maintainers name technical or creative debt (43%) and parity between design and code (37%) as their top challenges (Sparkbox Design Systems Survey 2022, 162 to 164 maintainers). AI agents add a new source: 59% of practitioners report interface bypassing the design system, and 44% of organisations tolerate it (zeroheight, State of AI in Design Systems 2026, 123 respondents).
Decay is a system falling behind its products. Products change every week. A system that does not change with them is used less, then worked around. Only half of systems are widely (40%) or fully (10%) adopted (zeroheight Design Systems Report 2025, just under 300 respondents). In research interviews, six of nine design-system leaders said keeping a system evolving with its products is hard (Lamine and Cheng, 2022).
Maintenance load falls on very few people. 3 in 5 design-system teams did not have enough people to meet their goals (zeroheight Design Systems Report 2026, 147 respondents). Average teams were three people at companies under 100 employees, four at 100 to 499 and nine at 500 or more (zeroheight Design Systems Report 2025). When the team is that small, support and repairs leave little time for the work that keeps the system current.
Nobody publishes an industry rate for detached components or duplicated code in design systems. Your own counts are better than any average, which is why the calculator asks for them.
Estimate the cost with your own numbers
Enter what you know about your team. Values marked as examples are there to be replaced. Values with a source come from the studies above, and you can change them too. The formula is printed under the result, so you can check every step.
Your estimate, from your inputs
- Drift, a year
- about 1,800 hours
- Decay, a year
- about 190 hours
- Maintenance load, a year
- about 2,900 hours
- Yearly cost of drift and decay
- drift and decay take about 3% of the product team's hours
- Clearing the backlog, once
- about 90 hours
- Value when the system is used, a year
- time given back, at the cited rates
- Running cost, a year
- the system team
- Return on what the system costs
- after drift and decay; below 0% the system costs more than it returns
Amounts are in the currency of your hourly cost, rounded to two figures and shown as a range. This is your estimate from your own numbers, not a claim by Loom. The value line uses published averages from small studies; replace them with your own measurements when you have them.
The formula
- Drift
(D + E) × r × W × Cevery person who builds interface, times the hours a week they spend redoing or reconciling, times the weeks and the hourly cost- Decay
P × R × m × Ceach product taking up each release- Maintenance load
T × H × W × s × Cthe system team's reactive share- Backlog (one-off)
x × f × Cclearing what has already drifted- Yearly cost of drift and decay
Drift + Decay + Maintenance load- Value when the system is used
(D × Zd + E × Ze) × u × H × W × Cthe time a working system gives back, on the share of work it covers- Running cost
T × H × W × Cthe system team- Return
(Value − (Running cost + Drift + Decay)) ÷ (Running cost + Drift + Decay)drift and decay count as costs because they are work the system was meant to remove- Range
each figure × (1 ± range); the return pairs low value with high cost, and the reverse
What each symbol means
Dproduct designers who use the systemEengineers who build product interfacePproducts that consume the systemCcost of one working hourWworking weeks a yearHworking hours a weekrhours per person per week spent rebuilding what exists or reconciling Figma and codeRsystem releases a year that products must take upmhours per product to take up one releasexknown detaches, local copies or open exceptionsfhours to resolve one of themTpeople on the design-system teamsshare of the system team's time spent on support, fixes and chasing driftZdtime saved by designers on work the system coversZetime saved by engineers on work the system coversushare of the week spent on work the system covers±uncertainty range
What Loom changes for each cost
Drift is found where it starts. The audit reads your repository and scores eight areas with evidence, including raw values and re-implemented components (how the audit works). Agents check their work against your system before hand-off, so off-system interface is caught where it is written (the verifier). Exceptions are allowed, and they end: each one lasts at most 90 days and returns to its owner when it expires (exceptions).
Decay is made visible before it spreads. Breaking changes are decided by a contract diff, not by opinion (breaking changes). Deprecations name a replacement and a date, and the audit reports every remaining use. Needs that people and agents could not find in the system are logged with request counts, so the owner sees what the system is missing (the list of needs). Each audit is stored in your repository, so every area shows a trend and a band change instead of a single reading. When a breaking change is proposed, Loom shows how many files and call sites it reaches, and its codemod writes the migration as a draft pull request for each consuming product. Needs that pass the owner's threshold become draft proposals with an owner. What does not work yet: none of this has run in a client's repository, and migration pull requests do not yet carry before and after screenshots.
Maintenance load moves from people to the system. Every request waits in one review queue with an owner, a due date and a service level counted in working days (the review queue). Agents receive your rules through an MCP server and an AGENTS.md pack, so routine questions are answered by the system (agents and MCP). The owner sees adoption, drift, flow and quality, and the page says "not measured" where there is no source (health).
Coming next
The Academy will certify the people who use your system and send each of them a short refresher when the system changes. Migration pull requests will carry before and after screenshots. Our first on-system evaluations will run the same tasks with and without Loom; when a real one exists, its numbers will appear on this page with their method.
What leaders should do
If you fund a design system, ask what it costs to keep, not only what it cost to build. Measure drift and decay once, now, so that you have a baseline. Then give the team the structure and the tools to keep those numbers down.
Drift is paid for whether it is budgeted or not. Budget for keeping the system, and it keeps paying back.
Questions
Is the calculator's result a promise from Loom?
No. It is your estimate from your own inputs. Loom does not cite savings figures until it has measured them in its own client work, and it has none yet.
Where do the default values come from?
Each input says. Some come from the published studies above, with a link. The rest are examples to replace with your own numbers.
Why does the result show a range?
Every input is an estimate, and the studies behind the cited values are small. A range is more honest than one precise number. You can change the width of the range.