Why design systems get cut, and how to build one that survives

They get sold as a design-quality project. They are actually an engineering cost-saving tool. That gap is why most of them fail.

Every company I have worked in eventually starts a design system. After a lot of work, in most of them it gets quietly defunded, half-adopted, or abandoned. Not because the work was bad, but because it was sold as the wrong kind of work.

A design system is almost always pitched as a design-quality initiative. Consistency. Brand. Polish. A single source of truth. All of that is real, and all of it sounds, to the people holding the budget, like a nice-to-have. So the moment money gets tight, the design system goes on the list with the other nice-to-haves. This is the core mistake: design arguing craft in a room full of people talking about numbers.

This system is actually the cheapest engineering decision your company will make.

The system does save designers real time, and it is worth being precise about that rather than overstating the case. A well-built UI kit ships screens faster, holds them consistent, and turns handover from a negotiation into a hand-off. Those savings are real. But they are the savings everyone already sees and already credits to the system, which is exactly why they do not win the argument in a budget meeting. They are also the smaller pool. A design team is a handful of people; the engineering team it feeds is usually many times larger, and engineering time is the expensive resource in software. The most expensive thing those engineers do is decide the same thing twice and build it three times. A button that has been designed once, named once, and built once stops being a decision. Every time someone reaches for it instead of inventing a new one, you have removed a meeting, a review, a round of QA, and a small argument. Multiply that across a year and a team, and the return was not the designer hours, but the recurring engineering time that was being spent without noticing.

That is why I treat a design system as a cost-saving tool first and a quality tool second. The consistency is a by-product. The real product is decisions made once.

One thing the people who sell system rarely admit is that it constrains designers. It takes options off the table. The third button style you wanted, the slightly different spacing, the clever one-off, those get harder and sometimes impossible. Designers feel this as a loss of creativity, because it is one. Pretending otherwise is why designers quietly resist the systems their own leaders build.

But that is the trade, and it is a good one. You give up local creativity and buy a shared language between design and engineering. Once that language exists, both sides move faster, because they stop renegotiating the basics every sprint. The creativity you lose is at the level of the button. The creativity you gain is at the level of the product, because the team’s attention moves up to problems that are actually worth solving.

So if the economics are this good, why do most systems fail? It is almost always for reasons that have nothing to do with design.

The first one is ownership. A design system is a product, not a project. It needs a roadmap, a maintainer, and a budget, the same as anything else you expect to keep working. Most companies fund the build and not the upkeep. So the system ships, the team moves on, the product keeps evolving, and within a year the system is out of date and people route around it. An unmaintained system is worse than none, because now everyone has a reason not to trust it.

And the drift is not only internal. The ground under the system moves too. Figma changes what a component can be, the tokens you hand-built become something the tool now generates for you, AI shifts what is cheap to make and what is even worth making.

The second is the codebase you are walking into. You almost never build a system into a clean product. You inherit a mature one, with hardened opinions and years of decisions baked in, often built and designed by developers, and it shows. Retrofitting a system into that is slow, political work. The system competes with the way things have always been done, and for a while you are running two systems at once, which costs more. People see that cost, do not see the future saving, and conclude the system was a mistake. But, it was only half-finished.

The most common version of this is the team that is convinced it already has a system because it has Tailwind. Tailwind is a styling mechanism, not a system. It will happily carry fifty subtly different buttons, each one locally reasonable. However, the cost behind this is the engineering hours described above. You are not looking for consistent style, but the decision being made once.

The third is that the people who paid for it were sold the wrong story. If you justified the system on aesthetics, it gets cut on aesthetics the first time the quarter looks bad. If you justified it on engineering cost and decision speed, it has a defence that survives a budget meeting.

So if you are building one, or trying to keep one alive, remember a few things.

Fund it as a product. If it does not have an owner and a maintenance budget, you are not creating an asset.

Bring engineering in from the first day, not as consumers of your system but as co-authors of it. Adoption is not a design problem you can solve with better components. It is an agreement, and people adopt agreements they helped write.

Measure the things that actually pay:

1. time to ship a new screen,

2. number of one-off implementations that stop appearing in the codebase,

3. questions engineering no longer has to ask design.

Those are the numbers that keep a system funded.

And be honest about the creativity trade with your designers. A system imposed on them is one they will quietly work around, and a worked-around system is just expensive documentation.

A design system is one of the few things a design team can build that pays for itself. That is exactly what makes it valuable, and exactly what makes it easy to lose. Sold as polish, it dies in the first downturn. Sold as economics, and built as a product, it becomes the rare piece of design work that nobody questions, because everyone can see what it returns.