When We Recommend a Monorepo
A monorepo pays dividends when code sharing between packages is frequent. If your web frontend, mobile app, and backend API share a design system, validation schemas, and TypeScript types, a polyrepo means those shared packages must be versioned, published to a registry, and updated with every change. In a monorepo, changing shared code is a single commit and consumers see it immediately.
Turborepo and Nx have largely solved the CI performance argument against monorepos with incremental builds (rebuild only what changed) and distributed caching (share build artifacts across CI runs). The historical CI time argument against monorepos is much weaker than it was three years ago.
When We Recommend Polyrepos
Multiple teams with truly independent deployment lifecycles and no meaningful code sharing. Services that communicate only via APIs with no shared types. Different repository access controls required for compliance reasons. Very large organisations where monorepo tooling itself becomes a full-time engineering effort.
Our Practical Default
For teams of 5–50 engineers with 2–6 closely related services: monorepo with Turborepo. It consistently pays for itself in reduced coordination overhead within the first month of the engagement. The setup cost is a few hours; the ongoing savings are material.