Monorepo Gravity Well
Teams adopt monorepos to simplify dependency management, enable atomic cross-project changes, and share code easily. Google and Meta run massive monorepos, so it must work. But those companies built custom tooling costing millions — Bazel, Buck, custom VCS. Most teams adopt monorepos with off-the-shelf tools (npm workspaces, Turborepo, Nx) and hit scaling walls within 12-18 months. CI pipelines slow to a crawl as every change triggers builds across the entire repo. Git operations degrade as the repo grows. Ownership boundaries blur — everyone can change everything, so nobody owns anything. The monorepo becomes a gravity well: easy to add projects, nearly impossible to extract them.
What people believe
“Monorepos simplify dependency management and improve code sharing.”
| Metric | Before | After | Delta |
|---|---|---|---|
| CI build time | 5-10 min per project | 30-60 min monorepo | +500% |
| Git clone time | Seconds | Minutes to hours | +1000% |
| Cross-project code sharing | Package publishing | Direct imports | Simplified |
| Project extraction cost | N/A | Weeks to months of work | Prohibitive |
Don't If
- •Your team is under 20 engineers and projects have clear boundaries
- •You don't have dedicated build infrastructure engineering capacity
If You Must
- 1.Invest in build caching and affected-project detection from day one
- 2.Enforce strict ownership boundaries with CODEOWNERS files
- 3.Use sparse checkout and partial clone to manage repo size
- 4.Define extraction criteria before projects enter the monorepo
Alternatives
- Polyrepo with shared packages — Publish shared code as packages, keep projects independent
- Focused monorepos — Group tightly coupled projects only, not everything
- Git submodules — Shared code as submodules — ugly but maintains boundaries
This analysis is wrong if:
- Teams adopting monorepos with off-the-shelf tooling report sustained CI performance at scale beyond 50 projects
- Monorepo adoption correlates with improved code ownership clarity rather than ownership diffusion
- Project extraction from monorepos is routinely accomplished in under one week
- 1.Google Monorepo Paper: Why Google Stores Billions of Lines in a Single Repository
Google's monorepo works because of massive custom tooling investment most companies can't replicate
- 2.Uber's Monorepo Migration Challenges
Uber documented significant CI/CD scaling challenges after monorepo adoption
- 3.Nx and Turborepo Performance Benchmarks
Build tools help but can't fully solve the fundamental scaling challenges of large monorepos
- 4.Microsoft 1ES: Lessons from the Largest Git Repo
Microsoft's Windows repo required custom VFS for Git to function at scale
This is a mirror — it shows what's already true.
Want to surface the hidden consequences of your engineering decisions?