The monorepo vs polyrepo debate has gone through phases. Google and Facebook publicized their monorepos in the 2010s and "monorepo good" became gospel. Then operational complexity hit smaller teams and "monorepo bad" backlash followed. The 2026 reality is more boring: each has tradeoffs, and the right answer depends on team structure, tooling investment, and code coupling.
This is what the tradeoffs actually look like once you have lived with them.
Definitions
Monorepo. Multiple projects (applications, services, libraries) share one repository. One git history, often one CI pipeline, often shared tooling.
Polyrepo. Each project has its own repository. Multiple histories, multiple CIs, looser coupling.
The defining feature is not the number of folders — it is the unit of versioning, branching, and CI. A repo with five Laravel apps and one combined CI is a monorepo. A repo per app, even if they live in the same GitHub org, is a polyrepo.
What Each One Optimizes For
Monorepos optimize for code sharing. When projects share code — a UI library, a domain types package, common utilities — having them in one repo makes changes atomic. Update the library and every consumer in the same commit.
Polyrepos optimize for team independence. When projects are owned by different teams with different release cadences, separate repos let each team move at their own pace without coordination.
Most arguments about which is "better" are really arguments about which property matters more for a specific team.
What the Monorepo Actually Costs
Tooling becomes a real investment. Off-the-shelf CI configurations break down when you have 30 services in one repo. You need:
- Affected-only builds (Nx, Turborepo, Bazel, Lerna). Without these, every change rebuilds everything.
- Path-aware CODEOWNERS so the right people review the right code
- Selective deployment that only deploys what changed
- A build cache (local and CI) to avoid recomputing identical work
The tools exist; the investment to adopt them well is real. A small team can sink months into monorepo tooling and not finish.
Code review gets weird. A PR that touches three apps requires expertise across them. Without strong ownership in CODEOWNERS, the review burden falls unevenly.
Branch sprawl is worse. With 30 teams pushing branches to one repo, the branch list becomes unusable without naming conventions and aggressive cleanup.
Permissions become coarse. If everyone has write access to the repo, "everyone has write access to every service." Fine-grained per-folder permissions exist but require care.
What the Polyrepo Actually Costs
Cross-cutting changes are painful. A schema change that touches three services means three PRs in three repos, coordinated rollout, multiple CI runs. Refactors that span services are friction-heavy.
Code duplication is the path of least resistance. "I need this utility too" → copy it to the new repo. Six months later, three slightly-different versions of the same code.
Shared libraries require versioning discipline. A library used by multiple services has to be a real package with a real version. Bumping it across consumers takes effort.
Onboarding takes longer. A new engineer learning the system has to clone N repos and understand how they connect. The architecture is implicit in the repo graph.
CI duplication. Each repo has its own CI config, often nearly identical. Changes to the CI process have to be applied N times.
Tooling That Makes Each Work
For monorepos:
- Nx or Turborepo for JS/TS — affected-only builds, distributed caching, task orchestration
- Bazel for polyglot or massive repos — Google-scale build system
- CODEOWNERS that map directories to teams
- Conventional commits to enable automatic versioning
- Build cache (Nx Cloud, Turborepo Remote Cache) shared across CI and developers
For polyrepos:
- A shared CI library (GitHub Actions reusable workflows, GitLab CI includes) to keep configurations consistent
- A internal package registry (Verdaccio, GitHub Packages, Cloudsmith) for shared code
- A meta-tooling repo that pins versions of common dependencies
- Renovate or Dependabot to keep dependencies in sync across repos
The lesson: both approaches require investment. The investments are just different.
When Each Actually Wins
Monorepo wins when:
- Multiple projects share substantial code (UI libraries, types, business logic)
- Cross-project refactoring is common
- Teams are small and overlap heavily on ownership
- You have the budget for build tooling investment
Polyrepo wins when:
- Projects are loosely coupled and rarely cross-cut
- Teams own complete projects with distinct cadences
- You want hard isolation (security, compliance, vendor-handoff)
- The tooling investment for a monorepo is not on the roadmap
The Common Middle Ground
Most production systems are neither pure monorepo nor pure polyrepo. They are federated monorepos — multiple monorepos organized by domain or team.
yourcompany/
├── frontend-apps/ ← monorepo of web apps + shared UI
├── backend-services/ ← monorepo of services + shared libraries
├── design-system/ ← one repo for the shared design tokens
├── infrastructure/ ← terraform / k8s manifests
└── docs/ ← documentation
Each repo is a coherent unit. Cross-repo dependencies exist but are bounded. The frontend team and the backend team can move independently while still benefiting from internal monorepo structure.
Most companies above ~30 engineers end up here. Pure monorepos work for some (Google, Meta, Stripe). Pure polyrepos work for some (early-stage startups, agencies with isolated client work). The federated approach is the default for everyone in between.
The Migration Story
Migrating between approaches is expensive. Polyrepo → monorepo is hard because git history fragmentation is painful to consolidate, and CI/tooling has to be built. Monorepo → polyrepo is hard because shared code has to be extracted to versioned packages, and the implicit dependencies between projects become explicit.
Pick a default and stay with it unless the cost is clearly higher than the migration. Most teams should not migrate; they should adapt their existing structure.
What Matters More Than the Choice
The repo structure debate gets too much attention. Things that matter more for the same team size:
- Whether code review is fast and meaningful
- Whether CI runs in under 10 minutes
- Whether builds are reproducible
- Whether deploys are simple and reliable
- Whether engineers know who owns what
A polyrepo team with great review practices outperforms a monorepo team with bad ones, and vice versa. The repo structure is one input among many.
A Practical Default
For a team starting in 2026:
- Under 10 engineers, single product: one monorepo with backend, frontend, and infra folders. Simplest setup, full atomicity.
- 10–50 engineers, multiple related products: federated monorepos by domain.
- 50+ engineers, mature platform: federated monorepos with strong CODEOWNERS, build caching, and selective deploy.
- Vendor or agency model (separate client codebases): polyrepo per client. Isolation is the feature.
Avoid premature monorepo migration. Avoid polyrepo sprawl. The structure should reflect how teams actually work, not how some FAANG company says it works at their scale.
Sizing up whether your repo structure is the right shape for your team — or whether it has drifted into either extreme? We help teams pick structures that match how they actually work. scopeforged.com