Design systems are usually argued for on consistency, and consistency is the least interesting thing they provide. What they actually buy is a reduction in the number of decisions a team has to make twice.
That is why the case for one is weak at the start of a project and strong shortly afterwards. On the first screen, every decision is being made for the first time regardless. On the second, you either reuse the first screen’s answers or quietly contradict them.
What it actually buys
A working system removes a category of conversation. Nobody relitigates spacing, focus states or how a destructive action is confirmed, because those were settled once and written down somewhere enforceable.
The saving compounds in the places people do not anticipate: in review, in QA, and most of all in the handover to whoever maintains the product next. A system is a large part of what makes a codebase legible to someone who was not there when it was written.
The point where it starts paying
Two conditions usually have to be true. There is more than one surface—a second screen, a second product, an admin view behind the customer-facing one—and there is more than one person making decisions about how it looks and behaves.
Until both hold, a system is overhead with a plausible story attached. After both hold, its absence is the thing costing money, and it will keep costing quietly rather than showing up as a line anyone can point at.
Build the constraints before the components
The most useful part of a system is rarely the component library. It is the smaller set of decisions underneath: the type scale, the spacing steps, the colour roles and their contrast behaviour, and the interaction rules that everything else is built from.
Those are cheap to define and expensive to retrofit. Components assembled on top of undefined constraints tend to encode one screen’s accident as though it were a rule, and the library then has to be unpicked before it can grow.
How systems stop being maintained
They stop when using the system is slower than going around it. If a designer cannot find the component, or an engineer cannot get a needed variant without a negotiation, both will reasonably build their own—and now there are two systems, one of them undocumented.
Keeping a system alive is mostly about keeping that path short. A system with fewer components and a clear way to extend them outlives a comprehensive one that is difficult to change.