Every design system is good on the day it ships. The components are consistent, the tokens are tidy, the documentation site is new. Judging a system at launch tells you almost nothing about whether it will still be useful when the team that built it has moved on.
The failure mode is social, not technical
Systems do not decay because the components were badly built. They decay because a team needed a variant that did not exist, had a deadline, and had no route to add one. So they forked. Six months and four teams later, you have four systems wearing one name.
Governance is the deliverable
The part of a design system engagement that determines its lifespan is the contribution model: who can propose a component, what review it needs, how a change propagates to consumers, and how long that takes. If adding a component takes three weeks and a committee, people will fork instead. If it takes two days and one reviewer, they will contribute.
- A documented proposal route that takes days, not weeks
- One named reviewer, not a committee
- Versioning that lets consumers upgrade on their own schedule
- A deprecation path, so removing things is possible
Build the twenty that matter first
A library of 140 components is the end state, not the starting point. Around twenty components carry most of any product. Ship those, get them adopted, and let the rest accumulate through the contribution model you just built. A system that is used and incomplete beats one that is complete and ignored.
The test
Six months after handover, ask who added the last component. If the answer is your agency, the governance did not work. If it is somebody on the client team who was not in the original workshop, it did.