When Does a Company Actually Need a Design System?
by Maven Team, Software Development
"Design system" has become one of those phrases that signals seriousness. It turns up in board decks and job specs and agency pitches, usually without a clear answer to the only question that matters: does this company actually need one right now, and if so, how much of one?
We get asked to build them. We also, fairly often, talk people out of building them — or at least out of building the version they had in mind. A full design system is a real product with a real maintenance cost, and committing to one before you have the problems it solves is an expensive way to feel organised.
This is an honest framework for making that decision.
What a design system actually is
A design system is not a Figma file. It is not a component library either, although it contains one. It is the shared contract between the people who design your product and the people who build it, made concrete enough that both sides can rely on it without a meeting.
In practice a working design system has three layers:
- Design tokens — the named, single-source-of-truth values for colour, spacing, typography, radius, shadow, and motion. Not "
#1B4DFF" scattered across forty components, but "color.brand.primary" defined once and consumed everywhere, in both the design tool and the code. - Components — the actual buttons, inputs, modals, and cards, built once, accessible by default, with their variants and states documented. The Figma component and the coded component are two views of the same thing, not two things that drift apart.
- Usage guidance — the rules a token and a component cannot enforce on their own: when to use a primary versus a secondary button, how empty states should read, what the spacing rhythm of a page should feel like.
The thing people underestimate is that all three layers have to stay in sync as the product changes. That synchronisation is the cost. A design system is less like a deliverable you finish and more like a garden you tend.
The signals that you genuinely need one
You need a design system when the absence of one is already costing you money. The tell-tale signs:
You are building the same thing more than once. Two teams have each built their own date picker. Three slightly different "primary" blues exist in production. A new feature ships and it looks subtly unlike the rest of the product because the engineer rebuilt the card component from memory. Every one of these is duplicated effort plus a consistency bug, and they compound.
More than one team or product shares a surface. A single small team building a single app can hold the conventions in their heads. The moment you have multiple squads, multiple products, or a web app plus a marketing site plus a mobile app that are all meant to feel like one brand, the in-the-heads approach stops scaling. The design system becomes the mechanism by which teams who never talk to each other still ship consistent UI.
Design and engineering keep relitigating settled decisions. If every pull request involves a conversation about padding, or a designer is annotating spacing values by hand on every mockup, you are paying a tax on decisions that should have been made once. A token system turns "is this 14 or 16 pixels?" from a recurring negotiation into a lookup.
You are scaling the team. Onboarding a new front-end engineer into a codebase with a documented component library takes days. Onboarding them into a codebase where every screen is bespoke takes weeks, and the result is more bespoke screens. A design system is partly a knowledge-transfer tool — it encodes "how we build UI here" so it does not live only in your senior people.
If two or more of those describe you, the conversation is no longer whether but how much.
The signals that you do not need one yet
This is the part agencies tend to leave out, because building you a design system is more billable than telling you to wait. But getting this wrong is genuinely costly, so here are the honest counter-signals:
You have one product, one small team, and the design fits in a few people's heads. A shared set of tokens and a handful of reusable components is plenty. A formal, governed, separately-maintained design system at this stage is a solution looking for a problem.
You have not found product-market fit. Before PMF, your UI should be changing constantly — that is the work. Freezing it into a formal system early means you are maintaining (and paying to change) infrastructure around a product whose shape you do not yet know. Move fast and stay loose; systematise once the shape stabilises.
Nobody owns it. A design system with no clear owner does not stay alive — it rots into a museum of components nobody trusts, and teams quietly go back to building their own. If you cannot name the person or small team who will maintain it after launch, you are not ready to build it. An abandoned design system is worse than none, because people waste time checking it before working around it.
You are reaching for it to fix an organisational problem. If design and engineering do not talk, a design system will not make them. It can support a healthy relationship; it cannot manufacture one. Fix the collaboration first, or the system will encode the dysfunction.
The cost nobody quotes you
The build cost of a design system is the part everyone estimates. The part that sinks projects is the running cost.
A design system needs a clear owner, a versioning and release process so consuming teams are not broken by changes, a contribution model for how new components get added, documentation that is kept current, and someone whose actual job includes saying no to one-off additions. None of that is glamorous and all of it is ongoing.
The honest budgeting question is therefore not "what does it cost to build?" but "can we sustain it after the people who built it have moved on?" If the answer is no, scope down until the answer is yes. A small, genuinely-maintained system beats an ambitious, abandoned one every time.
A pragmatic middle ground
The choice is not binary — full design system or chaos. There is a sequence, and most companies should walk up it rather than jump to the top.
- Start with tokens. Even a single-product team benefits from defining colour, spacing, and typography as named values in one place. It is cheap, it is low-maintenance, and it removes a whole category of inconsistency. This is the highest-return, lowest-cost step, and almost everyone should take it.
- Extract a component library. When you notice yourself rebuilding the same UI, pull the common pieces — buttons, inputs, cards, modals — into one accessible, documented library that your product consumes. You now have most of the practical benefit of a design system with a fraction of the governance overhead.
- Add documentation and usage guidance when more than one person or team needs to make decisions without you in the room.
- Formalise governance — versioning, contribution rules, a named owner, a roadmap — only when the system serves multiple teams and the cost of inconsistency justifies the process.
Most companies that ask us for "a design system" actually need steps one and two, done well, with a clear path to three and four when growth demands it. Building the full governed system on day one is how you end up with elaborate infrastructure and no product to put in it.
How to decide in one question
If you want a single test, it is this: what is inconsistency currently costing you, and who is going to maintain the fix?
If the answer is "a lot, across several teams, and we have someone to own it" — build the system, and treat it like the product it is. If the answer is "not much yet, and nobody has the bandwidth to maintain it" — define your tokens, extract your common components, and revisit the full system when growth forces the question.
The companies that get the most out of design systems are not the ones that built the most elaborate version earliest. They are the ones that built exactly as much as their problems justified, kept it alive, and grew it deliberately. Matching the investment to the actual problem is the whole skill — and it is the part the word "design system" tends to obscure.
If you are weighing this up and want a straight answer about where your product sits on that sequence, that is exactly the kind of thing we are happy to talk through on a short call — no pitch for more than you need.