Many frontend applications share components, tooling and types. Monorepo or separate repositories?

What actually decides it

Both models work at scale; each fails without specific investment.

A monorepo requires build tooling that scales. Without change-aware task execution, remote caching and test selection, every change runs the whole build and the developer experience degrades continuously as the repository grows. That tooling is a real ongoing investment, and organisations that adopt a monorepo without it end up with the coupling and none of the benefit.

Separate repositories require release discipline. Every shared change becomes a publish plus a coordinated upgrade across consumers, and consumers on old versions accumulate. Without automated dependency updates and a deprecation process, the estate fragments into applications on wildly different versions of everything.

The properties each gives

Monorepo: atomic cross-package changes, one version of everything, shared tooling and standards, easy refactoring across boundaries. Costs: build complexity, weaker enforcement of boundaries, everyone's changes in one history.

Polyrepo: hard boundaries, independent release cadence, small clear ownership. Costs: coordination for every shared change, version skew, duplicated tooling.

The hybrid that often wins

Shared libraries and design system in one repository; applications separate. Shared code gets atomic changes and consistent tooling; applications get independence. The cost is the publish step between them, which is the coordination point that hybrid deliberately keeps.

The honest signal

Which pain is the team actually feeling? Coordinating a shared component change across ten repositories, or a build that takes twenty minutes because everything is in one place. Choose against the pain that exists rather than the one described in an article.