When you actually need a design system

The question is usually asked as though a design system were a milestone — something a company graduates into once it is serious enough. It is not. It is a cost, paid up front, that buys one specific thing: the ability to change your mind about how the product looks without editing it in forty places.

So the question is not whether you are big enough. It is whether you are already paying for the absence of one.

What it actually buys

Not consistency for its own sake, and definitely not beauty. Three things, in order of how much they matter:

1. 01Change becomes cheap. Adjusting a corner radius, a shade of grey or a focus ring is one edit instead of a search. This is the whole return, and everything below is a consequence of it.
2. 02The same decision stops being made repeatedly. Every button someone designs from scratch is a small re-litigation of questions that were settled months ago, by somebody who may not know they were settled.
3. 03New people can be right by default. Someone joining does not have to absorb taste by osmosis to produce work that fits.

Note what is missing from that list: speed. A design system does not obviously make the first version of anything faster. It makes the fifth version cheaper, which is a different and less visible benefit — and the main reason it is hard to get funded.

The case against, taken seriously

Built too early, a design system is a tax on a product whose shape is still being argued about. Two real costs:

• You will systematise the wrong things. Abstracting a component before you have three genuinely different uses of it produces a configurable thing that fits none of them. The third use is where the real pattern becomes visible; before that you are guessing at it.
• It raises the cost of exploration. When adding a one-off needs a conversation about whether it belongs in the system, people stop adding one-offs — including the ones that would have turned out to be the good idea.

A product with eight screens and one designer does not have a consistency problem. It has one person's taste, which is the cheapest design system there is and needs no documentation.

The signals that it is time

These are symptoms of already paying the cost, which is what makes them more useful than headcount as a trigger:

• Two people built the same component differently, in the same week, without either knowing. The clearest signal there is.
• A designer is redrawing a button. Not designing one — redrawing the existing one, because there is no file to pull it from.
• You can't answer "which grey is that?" without opening a file and using a colour picker.
• Somebody proposed a change and the estimate was "a few weeks" for something that is visually trivial. That number is the cost of not having one, stated out loud.
• The same bug keeps coming back in a new place — the focus state, the disabled state, the thing that breaks on a long label.
• A new hire's first PR looks subtly unlike everything around it, and the review is about taste rather than correctness.

Start with the decisions, not the components

The common failure is to begin by building a component library — a month of work producing twenty components, most of which are used once. The cheaper order is the opposite.

Tokens first

Colour, spacing, type scale, radii, shadows, motion durations. These are small, they are the things most often inconsistent, and naming them delivers most of the "change is cheap" benefit on their own. A product with named tokens and no component library is already in much better shape than the reverse.

Then only what is genuinely reused

Promote a component on its third real use, not its first. Two uses is a coincidence; three is a pattern, and by then you can see which parts actually vary.

Write down why, not just what

A library of components is not a design system. The system is the decisions: when to use this rather than that, what the variants mean, what is deliberately not offered. Without that, people read the component list as a menu and pick by appearance, and the inconsistency reappears one level up.

Make the system refuse the wrong thing

A design system enforced only by convention decays, because convention loses to deadlines. The parts that survive are the parts the tooling makes awkward to bypass: typed variant names so a removed one becomes a compile error rather than a component silently rendering unstyled, tokens that are the only way to get a colour, lint rules for the handful of things worth refusing outright.

That is the same argument made at more length in TypeScript before you scale: the useful property is not catching mistakes, it is knowing the full extent of a change before you make it.

The short answer

Build one when changing your mind has become expensive, and not before. If you cannot name a change you wanted to make and did not because of what it would cost, you are early — and the right move is to name your tokens, keep one person's taste in charge, and wait for the third use.

If you are weighing this up for a product mid-flight, tell us what you are building.