Why We Built Our Own Design System (And Why You Should Too)

The threshold that justifies it

A design system pays off when the cost of inconsistency exceeds the cost of maintenance. For us the tipping point was concrete: four different button implementations, three spacing scales, and a redesign that would have meant editing dozens of files by hand.

Below that threshold, an off-the-shelf component library is almost always the better answer. Adopt one, theme it, and revisit when the friction is measurable rather than anticipated.

Start with tokens, not components

The durable layer is the tokens: colour, spacing, radius, typography and motion. Components change constantly; tokens barely move once they are right.

Defining tokens as CSS custom properties meant our dark theme became a redefinition of a dozen variables rather than a parallel stylesheet. It also made the system portable across frameworks, which mattered more than we expected.

• Define a restricted colour palette with semantic names, not literal ones.
• Use a single spacing scale and forbid arbitrary values in review.
• Set type scale and line heights once, then never override locally.
• Express every theme as a token override, never a component fork.

Constrain the API deliberately

The failure mode of an in-house system is a component that accepts every prop anyone ever wanted. It ends up as a styling escape hatch and the consistency benefit evaporates.

We kept variants few and explicit. If a use case does not fit, that is a design conversation, not a new boolean prop. Saying no here is most of the value the system provides.

What it actually bought us

The clearest gain was speed of change. A visual refresh that would previously have been a multi-week effort became a token edit reviewed in an afternoon.

The second gain was accessibility. Focus states, contrast ratios and keyboard behaviour are solved once inside the component rather than rediscovered per feature, which is the only way those properties survive contact with deadlines.