Monorepos — keeping multiple projects in a single repository — have become fashionable, partly because large companies like Google, Meta, and Vercel use them. The fact that Google uses a monorepo is not a strong argument that you should. Google's scale, tooling investment, and team structure are almost certainly nothing like yours.
Here is an honest look at the tradeoffs.
The Genuine Advantages
- *Atomic changes across packages. When a shared library changes its API, you can update all consumers in the same commit. With separate repositories, you version the library, publish it, then update each consumer repo separately — which is tedious and creates a window where repos are out of sync.
- *Shared tooling configuration. ESLint config, TypeScript config, testing setup — defined once and extended across packages. Not having to maintain N copies of the same configuration is a real quality-of-life improvement.
- *Code sharing without publishing. A shared
utilspackage used by both frontend and backend does not need to be published to npm. You just import it directly.
The Real Costs
- *Build tooling complexity. Getting incremental builds working correctly — only rebuilding packages that changed — requires investment in tools like Turborepo, Nx, or Bazel. Without this, CI builds get slower as the repository grows.
- *Repository size.
git cloneof a large monorepo is slow. Git history is shared across all packages, making tools likegit logandgit blamenoisier.
- *Onboarding complexity. A new developer joining a monorepo needs to understand the entire structure to work on one part of it. Separate repositories are more self-contained.
The Honest Recommendation
For a solo developer or small team (under ten people), a monorepo's advantages are mostly theoretical. The tooling overhead is real from day one; the coordination benefits only appear at team scale.
Start with separate repositories. Consolidate into a monorepo if and when the friction of cross-repo coordination becomes the actual bottleneck — not before.