Ten frontend teams share a design system. Monorepo or separate repositories?
Show the full answer Hide the answer
What is being tested
Whether you weigh atomic change against independent release, and whether you know what a monorepo requires to be viable.
The recommendation: monorepo, with conditions
Ten teams sharing a design system is the strongest case for one, because of a single decisive property:
Atomic cross-project changes. Update a shared component and every consumer in one commit, with CI verifying all of them. In a multi-repo setup, changing a component means publishing a version, then ten separate upgrade pull requests, each on its own schedule — and within a quarter the ten teams are on six different versions, which is the actual failure mode.
Also: one dependency version eliminating incompatible-version bugs; shared tooling; discoverability; and refactoring across boundaries.
What it requires to be viable
This is not optional above a modest size:
- Affected-project detection, so CI runs only what a change touches. Without it, CI runs everything on every change and becomes unusably slow.
- Build caching, which is what makes a large monorepo work at all.
- Enforced boundaries via lint or build rules, because reaching across a boundary is easy and therefore happens.
- A code-owners file, so review routes correctly and ownership is unambiguous.
If the organisation will not invest in that tooling, the monorepo becomes a slow, tangled repository and multi-repo is the better choice.
What it costs
Coordinated upgrades — one dependency version means everyone upgrades together, which is both a benefit and a constraint. Repository size affecting clone times. Coarser access control.
When multi-repo is right
Genuinely independent projects. Teams needing independent release cadence. Access restricted per project.
The hybrid, which is common and reasonable
A monorepo per domain or per team, with published packages between domains. Atomic change where code is genuinely shared, independence where it is not. For ten teams this is frequently the pragmatic landing point.