When Polyrepo Is the Right Call
and Why You Probably Don’t Need a Monorepo
If you are under 30 engineers and not actively feeling monorepo-shaped pain, don’t migrate. The tooling investment is real. The benefit is not guaranteed. This page is for teams that have been told “you should consolidate” when they probably should not.
The Pain Test
Answer these 5 questions. If you answer “no” to all of them, you do not have a monorepo problem.
1. Do you regularly need to land commits in 3+ repos simultaneously?
If YES: you have a monorepo pain point.
2. Are cross-team dependency updates taking more than a week to propagate?
If YES: dependency management is breaking down.
3. Is CI time scaling linearly with the number of repos you add?
If YES: repo-count scaling CI problem.
4. Are engineers spending significant time coordinating releases across repos?
If YES: release coordination overhead.
5. Is copy-paste across repos a widespread pattern for shared logic?
If YES: code sharing problem (but solvable without monorepo).
The Hidden Costs of Monorepo Tooling
These costs are real and often underestimated. The vendors do not put them in their blog posts.
CI rewrite
A monorepo requires a fundamentally different CI strategy: affected-only builds, proper caching setup, incremental test runs. If you just run all tests on every commit, a monorepo makes CI worse, not better. Budget 1-4 weeks of platform engineer time for CI redesign.
Build tool learning curve
Bazel has one of the highest learning curves of any developer tool. Nx requires understanding its workspace graph and project.json model. Turborepo is simplest, but even it requires cache configuration. Factor 2-4 weeks ramp-up per engineer.
Onboarding cost
A 10,000-file repo takes 3-5 minutes to clone fully. At 500k+ files, you need git partial-clone or sparse checkout. New engineers need to learn which packages they can touch. The monorepo is not simpler to navigate than a well-organised polyrepo.
Tooling costs
Nx Cloud: free up to 50,000 CI minutes/month (2026 pricing), then paid. Turborepo Remote Cache: free with Vercel hosting, separately billed without. BuildBuddy (Bazel remote cache): free tier available, paid for enterprise. EngFlow (Bazel cloud exec): custom pricing. Factor these into the TCO before deciding.
For the onboarding cost angle: engineering hiring cost context
Polyrepo Strategies That Work
These tools solve the coordination problems that drive monorepo migrations, without the migration.
Private npm registry
Verdaccio docs →Verdaccio (self-hosted, free), GitHub Packages, or npm private org. Publish shared utilities as properly versioned packages. Semantic versioning enforces intentional breaking changes. This is how code sharing works in polyrepo without the monorepo.
Dependency dashboard automation
Renovate docs →Renovate Bot or GitHub Dependabot automatically opens PRs for dependency upgrades across all repos. Grouped by package, scheduled by window. Removes manual propagation work from engineers. This solves 80% of the monorepo dependency management argument.
Contract testing
Pact docs →Pact or similar contract testing frameworks verify that service API consumers and providers stay compatible. Decoupled from repo layout. Atomic commits across services are not the only way to enforce compatibility.
Shared CI config via git refs
GitHub Actions supports reusable workflows (workflow_call). GitLab has include blocks. You can maintain a central CI config repo and reference it from every service repo. One update propagates everywhere.
When to Revisit the Question
These are the genuine trigger conditions for a monorepo migration. If none of these apply, stay put.
- ➞
You cross 50 engineers and start making weekly cross-service atomic changes
- ➞
Your private package registry is becoming a bottleneck (slow propagation, version drift)
- ➞
15+ services all share the same core library and bumping it takes more than 3 days per cycle
- ➞
You hire a platform/DevEx team and they have the bandwidth to own build tooling
- ➞
A vendor dependency (security patch, license change) needs simultaneous update across 20+ repos
Related: Decision tree · Is Lerna still maintained? · By team size