Design systems get pitched to executives as a consistency initiative, which is true and rarely sufficient to get funded. Consistency sounds like tidiness, and tidiness competes poorly against a roadmap.
The stronger argument is about delivery cost. A design system changes the marginal cost of every feature you ship afterward, and that is a number the person holding the budget already cares about.
Where the time actually goes
On a team without a system, each new feature involves designing components that already exist elsewhere in some form, engineers interpreting spacing and states from a mockup, a review cycle catching inconsistencies, and rework. None of it is dramatic. All of it recurs on every feature.
With a mature system, a designer composes from existing components, engineers implement against documented tokens and states, and review focuses on whether the feature is right rather than whether the button is the correct grey. The saving compounds because it applies to every feature, indefinitely.
Tokens are the part that matters
Most failed design systems are component libraries without a token layer. Components get built, then someone needs a slightly different spacing, adds a one-off value, and within a year the library contains four button variants that differ by two pixels.
Tokens — a defined scale for spacing, type, color roles, radius, elevation and motion — are what makes the system a system rather than a collection. They also make theming, dark mode and rebrands tractable, because changing a token propagates everywhere instead of requiring a search across the codebase.
Specify every state or expect drift
The most common gap between design file and built product is states. A component is designed in its default appearance; hover, focus, active, disabled, loading, error and empty are left to interpretation. Engineers then make reasonable decisions that differ from each other.
- Every interactive component needs its full state set defined, including focus, which is frequently forgotten and is an accessibility requirement.
- Empty and error states need designing, because they are what users see when something goes wrong — precisely when a polished experience matters most.
- Loading behavior should be specified, since inconsistent loading treatment is one of the most noticeable forms of drift.
Systems die from neglect, not from bad design
A design system needs an owner and a contribution process. Without them, teams under deadline pressure build one-offs, the system falls out of date, and it becomes an obstacle people route around rather than a tool they use.
The maintenance burden is modest — usually a fraction of one person's time on a mid-sized product — but it is not zero, and pretending otherwise is how systems quietly stop being maintained six months after launch.
The question is not whether you can afford to build a design system. It is whether you can afford to maintain one.
If the answer is no, build a smaller one. A token layer and ten well-specified components maintained properly is worth considerably more than sixty components nobody updates.