Ten applications consume one design system and upgrades keep stalling because each app schedules them separately. Which release and consumption model keeps the total upgrade cost bounded as applications are added?
Show the full answer Hide the answer
The deciding property
Whether the cost of a change is paid once by the changer or N times by the consumers. Every model on this list is a different answer to that question, and it is the only question that matters as N grows.
With independent versioning, a breaking change is authored once and absorbed ten times, by ten teams with ten sets of priorities. The upgrade cost is therefore proportional to the number of applications and to how far behind each has drifted - and drift compounds, because the further behind you are the more expensive catching up becomes, which is why upgrades stall.
With one rolling version in a shared repository, the author of a change makes it compile everywhere before merging. The cost is paid once, by the person with the most context, at the moment they have it.
Why the other options fail
- "Independent packages, own schedule." The default, and it works well up to two or three consumers. At ten it produces a version spread of several major releases, so the library team maintains compatibility with all of them and every fix must be backported. The cost is invisible because it is distributed.
- "Vendored copies." Removes upgrade pain by removing upgrades. After a year there are ten divergent component libraries with a common ancestor, and the shared design is gone - which was the point of having a design system.
- "An LTS branch per major version." Sound for external consumers you do not control, and pure overhead internally: you are funding parallel maintenance to avoid coordinating teams that work for the same company.
What would flip the decision
| If this changes | Choose | Because |
|---|---|---|
| Consumers are outside your organisation | Independent versions and an LTS branch | You cannot run codemods in someone else's repository |
| Applications deploy on genuinely independent risk profiles - one is regulated, one is not | Independent versions with a supported range | Forced simultaneous change is unacceptable when one consumer's release requires an approval cycle |
| Repository tooling cannot handle the combined size | Independent versions plus automated upgrade pull requests | The monorepo answer depends on build-graph scoping actually working |
| There are two or three applications | Independent versions | The coordination cost exceeds the drift cost at that size |
When this is the wrong answer
A monorepo is not free. It requires build-graph scoping so a component change does not rebuild everything, a merge queue that can handle the combined change rate, and ownership rules so the design system team is not approving every product change. Without those three, the model produces a slow, contended pipeline and teams will route around it - which is worse than the drift it was meant to fix.