A design system is the answer until it is the answer to a question nobody is asking.
The first eighteen months of any growing product, consistency is the bottleneck. Buttons look different, modal padding varies, headers contradict each other across modules. The team rallies, builds the library, names the tokens, and shipped surfaces start to converge. This is good work and it is necessary.
What is not honest is what happens next. By month twenty-four, consistency is no longer the bottleneck. The bottleneck has moved. It is now flow logic, error states, edge case coverage, the seventeen things the customer success team has been quietly fixing in support tickets. But the design system team keeps shipping library updates because that is what they know how to do. The library becomes a place to hide.
The signal I look for is the ratio of library updates to product surfaces that benefit from them. When that ratio inverts, when more time is going into the system than into anything the customer touches, the system has stopped being the answer. It has become the work.
The honest move is to mark the library as done at a specific level of completeness, freeze the team’s attention on it, and redeploy that attention to whatever the actual second-act problem is. At one product, the second-act problem was that every new vertical needed its own configuration paradigm and the library had nothing useful to say about configuration. At another, the problem was error and empty states across thirty surfaces, none of which the library had a defensible position on.
The counter-view is that systems decay. Stop investing and entropy returns. This is true. The mitigation is maintenance, not new components. Maintenance is a different cadence and a smaller team.
The shift is to stop measuring a design system by how rich it is and start measuring it by what bottleneck it removes this quarter. If the answer is “none, but it is much richer,” the system is the work and the work has stopped being the product.