A design system is supposed to make a small team move like a big one. Somewhere along the way, a lot of teams flipped that around. They built a big system to serve a small product, then hired people to keep the system alive. I have watched a company with fifteen people building the actual product carry a standing crew whose whole job was maintaining the system those fifteen people were supposed to be helped by. That is not leverage. That is a tax you pay every sprint, and most teams never stop to ask whether it still pays for itself.
I build and lead design systems, so read this as coming from someone who believes in them. I wrote that design systems are the foundation AI builds on, and I meant every word. But a foundation you cannot afford to pour is not a foundation. It is a hole you keep filling. The question nobody asks out loud is when a system stops being an asset and turns into overhead. This is my answer, along with the signals that tell you which side of that line you are on, and how to step back off it without breaking the product.
What a system is supposed to buy you
A design system earns its keep on one piece of math. The cost of building and maintaining it has to stay smaller than the cost of the inconsistency and rework it prevents. When you have forty engineers and twelve designers each about to invent their own dropdown, that math is easy. The system pays for itself in a week, because the alternative is forty versions of everything and a product that feels like forty products stapled together.
I have lived the good version of this. For a two-app launch I once built a single shared system and shipped both iOS apps off it, and the second app went faster than the first because most of the decisions were already made. A new screen was an assembly job, not a blank page. That is what a system is for. It front-loads the thinking so everything after is composition. When the team is large and the surface is wide, that trade is one of the best in software.
The problem is that the math does not hold still. As the team shrinks, or the product narrows, or the pace of change slows, the value of prevented inconsistency drops while the cost of maintenance stays flat or climbs. A system that returned ten to one at forty engineers can quietly slide to one to one, then underwater, and nothing on the roadmap flags the moment it crossed over. The system does not announce that it stopped paying. It just keeps sending you the bill.
The signals it has become overhead
The clearest signal is the ratio. If the number of people maintaining the system is a real fraction of the number of people shipping the product, stop and look hard. A dedicated full-time system team for a fifteen-person product is not maturity. It is a liability wearing a maturity costume. You have taken people off the thing customers pay for and put them on the scaffolding around it.
The second signal is that the survey data lines up with what you feel. In Sparkbox’s 2022 Design Systems Survey (opens in new tab), the top reported challenges were not design problems, they were overhead problems: 43 percent named overcoming technical and creative debt, 36 percent named adoption, and 35 percent named staffing the system. When a third or more of teams say the hardest part of their design system is keeping it staffed, adopted, and out of debt, that is the sound of the tool costing more than it returns.
The third signal is upkeep with no upside. Nielsen Norman Group puts it plainly: a design system is "only as effective as the team that manages it," (opens in new tab) and it requires "continuous maintenance and oversight" so it does not become outdated or overcrowded. That is a feature when the maintenance buys you consistency across a big org. It is a trap when you are pouring that same continuous effort into components three people use twice a quarter. Read your last few months of system tickets. If most of them are version bumps, doc fixes, and keeping the library in sync with a product that barely moved, you are maintaining a museum, not a system.
A dedicated full-time system team for a fifteen-person product is not maturity. It is a liability wearing a maturity costume.
There are more tells once you start looking. Designers route around the system because filing a component request is slower than just building the thing. The library has nine buttons and nobody can say which one wins. The system roadmap has its own OKRs, disconnected from any customer outcome. Onboarding a new hire to the system takes longer than onboarding them to the product. Each of these on its own is a fixable bug. Together they mean the system has become its own product, and you are its only customer.
Scaling is the default, and that is the mistake
When a system starts to hurt, almost every team reaches for the same move: scale it. Add a governance process. Add a contribution model. Add a council, a Slack channel, a rotation, a roadmap. More structure to manage the structure. I understand the instinct, because scaling feels like progress and killing feels like failure. But you are treating a cost problem by adding cost. If the system already takes more than it gives, a bigger system takes more than that.
The real reframe is that a design system is not a trophy you level up. It is a tool that fits a specific team at a specific size. The right amount of system for a fifteen-person product is small. A tidy set of tokens, a dozen real components, and a page of rules that say this is how we do buttons and empty states. That is not a lesser system. That is the correct-sized one. The failure is not having a small system. The failure is running an enterprise system on a startup and calling the overhead maturity.
How to wind one down without breaking the product
Killing a design system does not mean deleting it and letting the product rot. It means shrinking it back to the part that earns its keep and freeing the people stuck maintaining the rest. You do it in the open, in steps, so nothing breaks.
Start by freezing new system work for a sprint and measuring what actually gets used. Instrument the components. Most libraries follow a brutal power law, where a handful of components carry almost all the usage and the long tail is dead weight. Pull the real numbers before you touch anything, because memory lies and the data does not.
Then collapse to the core. Keep the tokens, keep the ten or twelve components that show up everywhere, keep the handful of rules people actually follow. Everything in the dead tail gets one of two fates: absorbed back into the product code as a plain local component, or deleted. A component that lives in two screens does not need to live in a shared library with its own versioning and docs. It needs to just be code in those two screens. Moving it out of the system is not losing it. It is putting it where it belongs.
I did a version of this with the last system I inherited, a ten-year-old patchwork built on three different frameworks. We did not try to scale it. We rebuilt a small tokenized core, shipped that first, and grew it from there.
Do the migration behind the current interface so the product never notices. Swap the underlying implementation while the component API stays put, ship it in small pieces, and verify each one against the live product, not the design file. The gap between the file and the shipped app is where these projects go wrong, so treat the running product as the source of truth. And measure the win the way you would any other project, by the hours you hand back to the people who were maintaining the tail. If you want the method for putting a number on it, I wrote up how I measure design ROI, and the same discipline applies here in reverse: prove the overhead you removed.
When you are done, you have not killed design systems as an idea. You have killed a specific system that outgrew its team, and replaced it with a smaller one that fits. The three people who were tending scaffolding are back on the product. The core still keeps things consistent. The bill got smaller and nothing broke.
When killing it is the wrong call
The stance cuts both ways, so here is the other side. Sometimes the overhead is real and you should still keep scaling. If you are genuinely growing, if the fifteen people are about to be fifty, if you are heading into multiple products or platforms, then a system that looks over-built today is under-built for where you land next year. Building the foundation ahead of the growth is the right call, and I would not tell you to tear it down on the eve of a scale-up just to save a few months of cost.
There are two more cases where you keep it. One is when the system is what lets AI generate usable work, because a machine copying a loose system produces fast, confident inconsistency, and a tight system is the thing that keeps generation on the rails. If your system is doing that job, it is earning its keep in a way headcount math alone will miss. The other is regulated or safety-critical work, where consistency is not a nicety but a compliance and trust requirement, and the cost of drift is measured in lawsuits, not vibes. In those worlds the maintenance is the point.
So the test is not size alone. It is whether the system returns more than it costs for the team you actually have and the future you can actually see. For a stable fifteen-person product with no scale-up in sight, a full-time system team almost never passes that test, and the brave, correct move is to shrink it. For a company sprinting toward fifty across three products, the same spend is an investment. Same tool, opposite answer, and the only way to know which one you are is to run the math straight instead of defaulting to scale because killing feels like defeat.
A design system is a means, not a monument. It exists to give a team leverage, and the day it starts taking leverage away is the day you are allowed to make it smaller. Most teams never give themselves that permission. They scale past the point of payback because the system became something they are proud of, and pride is a bad reason to keep paying a tax. Measure it, size it to the team you have, and be willing to kill the version that outgrew you. The product is the point. The system was only ever there to serve it.