Why 'Monorepo vs Polyrepo' Is the Wrong Question
TL;DR: The repo strategy debate is a proxy for real questions about ownership, dependency management, and CI cost. Frame those directly and the repo layout falls out.
The framing that misleads
'Should we use a monorepo?' is a question that hides three questions: who owns what, how do dependencies move, and what's the CI budget? Answer those, and the repo layout is determined for you.
Question 1: Who owns what?
If one team owns most of the code, a monorepo is friction-free. If many teams own slices that change at different speeds, a monorepo can become a coordination tax — every change has to pass shared CI, even when it touches one slice.
Question 2: Dependency velocity
Monorepos push everyone onto the same versions of shared libraries. That's a feature when versions move fast and you want everyone in lockstep; it's a tax when one consumer needs to upgrade slowly.
Question 3: CI cost
A naive monorepo runs every test on every commit. A real one (Bazel, Nx, Turbo) runs only what changed. If you can't afford the tooling investment for change-detection, you can't afford a monorepo.
A heuristic
Under 5 services, one team: monorepo with no special tooling, just folders.
5–30 services, 1–3 teams: monorepo with Turbo/Nx for change detection.
30+ services, many teams: polyrepo with shared internal package registry.
These are starting points, not laws — but they fit most teams I've worked with.