Every product team we talk to knows they should have a design system. Most of them don't have one. And the reasons they give—"we're too early", "we don't have the bandwidth", "we'll do it after the next release"—are exactly the conditions under which you need one most.
What a design system actually is
A design system is not a component library. It's not a Figma file. It's a shared language between design and engineering that makes decisions once and applies them everywhere. At its core: a token layer (values like colour, spacing, typography), a component layer (reusable UI built on those tokens), and a documentation layer (the rules for when and how to use them).
The token layer is where most teams underinvest. When you define colour as a semantic token—`color.action.primary` rather than `#1a56db`—you gain the ability to theme, dark-mode, and rebrand without touching a single component. That flexibility compounds over time.
The real cost of not having one
At Atlas Finance, six product squads were building independently. Our initial audit found 1,400 unique colour values across their codebases—for a product with a brand palette of eight colours. Every squad had reinvented the same button component. The average time to build a new screen from scratch was three days; after the design system, it was four hours.
1,400
Unique colour values found
34
After consolidation
68%
Faster component builds
The hidden cost isn't the duplicated code—it's the cognitive overhead. Every engineer who builds a button from scratch is spending mental energy on a solved problem. Every designer who redocuments a spacing value is doing work that shouldn't exist. A design system redirects that energy toward problems worth solving.
When to invest
The inflection point is earlier than most teams expect. In our experience, a design system becomes ROI-positive the moment you have two product squads, two customer-facing surfaces, or two years of design debt. Below that threshold, a well-organised component folder is sufficient. Above it, the system pays for itself in the first quarter after launch.
Rule of thumb: if you've ever copy-pasted a component between two repos, you need a design system.
How to start without a six-month project
- 1.Audit first. Count your colour values, spacing scales, and button variants. The number will motivate the investment.
- 2.Start with tokens, not components. A token architecture can be adopted incrementally; a new component library cannot.
- 3.Build Storybook from day one. Documentation is not optional—undocumented components get bypassed.
- 4.Measure adoption with linting rules. If components are used, the system is working. If they're bypassed, something is wrong with the component, not the team.
- 5.Ship a v1, not a v1.0. A system with 30 components everyone uses beats a system with 300 components nobody trusts.
The teams that delay design systems are usually the teams that most need them. The discomfort of investing before you feel ready is the signal that the investment is overdue.
