The pitch for a design system is efficiency. Build the button once, use it four hundred times. The arithmetic is real and the savings arrive. What the arithmetic omits is that a design system is a product with users, and products with users need people.
The eighteen-month cliff
Systems tend to fail on roughly the same schedule. The launch is celebrated. Adoption climbs for two quarters. Then the team that built it moves to something else, requests queue, and product teams start forking components locally because waiting is worse than duplicating.
By month eighteen there are three versions of the button and the system is now a tax rather than a saving.
An unowned design system is not a neutral asset. It decays into a source of disagreement.
What ownership actually costs
In our experience the sustainable minimum is smaller than people fear: roughly a third of one designer and a third of one engineer, permanently. Not a team. A standing fraction of two people, with the authority to say no.
- A published intake path, so requests do not arrive as hallway asks
- A stated response time, even if that time is three weeks
- A documented deprecation policy, so removal is normal rather than dramatic
- One person who can decline a request without escalating
Build less than you want to
Every component you ship is a component someone must maintain. We now start engagements by cutting the proposed library roughly in half and pushing the remainder into per-product code, where it can be wrong cheaply.
A system of twenty well-owned components beats a system of ninety abandoned ones, and it is not close.