Monorepo or Polyrepo by Team Size:
2026 Recommendations
Team size matters more than codebase size. Here is the honest breakdown for startups, mid-size teams, and enterprises. Engineering hiring cost context
Startup (1-10 Engineers)
PolyrepoAt 1-10 engineers, the default is polyrepo per service. The overhead of setting up and maintaining monorepo tooling (even Turborepo) is not justified when the team is small enough to coordinate verbally.
Exception: JS/TS-only with < 5 services
If your entire stack is JS/TS and you have fewer than 5 services, a Turborepo monorepo is a two-day project. The caching alone can pay for setup time. But it is optional, not required.
Evidence
Most Y Combinator companies run polyrepo through series A. The coordination overhead at small scale is lower than the tooling setup cost. Move fast, ship, revisit repo layout at 20+ engineers when the pain is real.
Mid-Size (10-100 Engineers)
Decision ZoneThis is the decision zone. Most teams that migrate to a monorepo are in this range. It is also where the most wrong decisions are made. The key question: do you actually have a monorepo-shaped pain point, or do you just think you should consolidate because larger companies do?
JS/TS heavy stack
Turborepo for speed and minimal config. Nx for code generation, dep graph visualisation, and architectural enforcement. Both have free tiers for remote caching.
See: Nx vs Turborepo
Polyglot stack
Bazel 7+ for backend-heavy polyglot (Go, Java, C++). Pants 2.x for Python-heavy stacks. Both require dedicated platform engineer time. Do not start without budget.
Platform team investment: platform engineering cost
Real Example: Cash App / Block
Block (formerly Square) consolidated approximately 450 JVM services into a monorepo. The migration was multi-quarter. It took roughly 2 years to feel the full productivity win from the consolidation. Source: Block Engineering Blog
Enterprise (100-1000+ Engineers)
Usually Monorepo or HybridAt enterprise scale, the coordination overhead of polyrepo becomes a real drag. Most large engineering organisations end up at some form of monorepo, often hybrid: one monorepo per bounded domain, polyrepo across domains.
2 billion lines of code, Piper VCS (custom), Bazel, 25k+ engineers. Purpose-built tooling.
Source →Meta
Mercurial fork (Sapling) for partial-clone at scale. Unified repo across Android, iOS, web, server.
Source →Microsoft
Rush Stack per product (Windows, Office, VS Code each have their own approach). Not one global monorepo.
Source →Key lesson from enterprise scale
No enterprise runs a single monorepo for every team without a dedicated build platform team and custom tooling. If you are planning an enterprise monorepo, budget for a platform team. Without one, the monorepo becomes a shared-responsibility nobody owns.
Related: Decision tree · Tool comparison · Case studies · Migration cost