The hidden cost of a design system

I have built and maintained around a dozen design systems over the last decade, in companies ranging from twelve people to about two thousand. Every time I do this I notice the same dynamic: a design system can be enormously leveraged or enormously over-built, and the difference between those two outcomes is almost always set in the first three weeks of the project. The temptation, in week one, is to build every component you can imagine the team needing. The discipline, in week one, is to build only the components your team is actually going to reach for in the next two quarters.

The over-built design system is a familiar artefact. It has a beautifully-organised Figma file with eighty-five components, four hundred variants, and a comprehensive documentation site. It also has a maintenance bill the team cannot afford to pay. A new joiner cannot find what they need because there is too much to wade through. A change to one primitive ripples through dozens of components, half of which are not used in production, but all of which must be kept in sync because nobody is sure which ones are dead. The system becomes a parallel codebase that needs its own ongoing engineering attention, on top of the actual product codebase. After about eighteen months, the system is silently abandoned, and the team is back to ad-hoc mocks — but now with the additional shame of having built a thing that nobody uses.

The right-sized design system is harder to spot because it does not look impressive. It has somewhere between twenty and forty components. Each component is the simplest possible expression of its function. The token layer is small — maybe thirty design tokens for colour, twelve for typography, eight for spacing. The system is small enough that the entire team can hold it in their heads. New components are added quarterly, on demand, against a documented contribution flow. The maintenance bill is low because the surface area is low. The team uses it because it is genuinely useful, not because they have been told to.

When we scope a design system engagement for a new client, we spend most of the first week trying to argue the scope down rather than up. The question we keep returning to is not "what could we put in this system?" but "what would the team genuinely reach for in the next sixty working days?" That is almost always a much smaller number than the team initially expects, and the system that gets shipped is much smaller, and the team adopts it because it is small enough to adopt. The cost of a design system is not the cost of building it; it is the cost of maintaining whatever you build for the rest of the product's life. Right-sizing it is the most valuable design decision we make on any system engagement.