Does a small team need a design system?

The honest trigger is coordination cost. One developer building one product does not need a design system, because consistency lives in one person's head and that is cheaper than any documentation.

The cost appears when a second and third person start building interface, and the same button exists three times with slightly different padding. It appears again when you have more than one surface — a marketing site and an application, or a web app and a mobile app — and a brand change means finding every instance by hand.

So the useful question is not "are we big enough" but "how often do we re-decide something we have already decided?" If a developer has to guess which grey to use, that decision is being made repeatedly and inconsistently, and tokens will pay for themselves almost immediately.

Tokens are the named decisions underneath everything else: your colour palette, your type scale, your spacing steps, your radii, your shadows. They are a fraction of the work of a component library and they deliver most of the consistency benefit.

Keep the sets deliberately small. Five or six spacing values, not twenty. A type scale of six sizes. Enough greys to build interface, not a continuous ramp. Constraint is what makes a system usable — when there are forty options, people pick arbitrarily and consistency disappears anyway.

Define them once in a form both design and code consume. In our own work that means CSS custom properties that the design tool mirrors, so a change to a brand colour is one edit rather than a search across a codebase.

The rule that prevents over-building: a pattern earns a component on its third use, not its first. Extracting after two occurrences is speculation about how the pattern will vary, and speculative components tend to acquire props for cases that never arrive.

For most products the genuinely reusable set is small — button, input, select, card, modal, table, and a few layout primitives. That covers the large majority of interface, and it is achievable in a couple of weeks rather than a quarter.

Everything else can stay local to the page that needs it. Not every element must be a documented component, and treating that as the goal is how a team ends up maintaining a library instead of shipping a product.

The benefit that justifies the effort is not visual consistency, which clients notice, but accessibility, which they usually do not until it becomes a problem.

Getting focus states, keyboard interaction, colour contrast, and ARIA semantics right is genuinely difficult and easy to get wrong. Doing it once inside a component means every use inherits it, and a team that would never audit fifty buttons individually gets correct behaviour by default.

This matters commercially in our markets. EU public sector and enterprise procurement increasingly asks for conformance, and retrofitting accessibility across an inconsistent interface costs far more than building it into a dozen shared components at the start.

Bake the requirements in: contrast ratios validated in the token palette, a visible focus style on every interactive component, and reduced-motion alternatives for anything animated.

They fail by being too large. A system documenting two hundred components that nobody can navigate gets bypassed, and bypassed systems are worse than none because now there are two sources of truth.

They fail by being too rigid. If building something new requires a week of negotiation with the system, people will work around it. A good system has a clear escape hatch for genuine one-offs.

They fail by being unowned. Documentation drifts from implementation, the examples stop matching the code, and trust evaporates. Keeping documentation generated from the components themselves rather than written separately is the most reliable defence.

And they fail by starting too early. A pre-product-market-fit team writing a design system is optimising for a future that may not arrive. Build the product, notice what repeats, extract that.

If you have two to five people building interface, this is what we would put in place, and no more.

Tokens for colour, type, spacing, radius, and shadow, defined in code as the single source of truth. Around a dozen components covering the patterns you have already repeated. Documentation that lives next to the code and shows real usage. And one convention for how new patterns get added, so the system grows deliberately rather than by accident.

That is a two to three week investment for a small team, and it is the point of diminishing returns for most products under significant scale. Expand it when you feel the friction, not in anticipation of it.