The debate that never dies
Every few months it comes back. A blog post, a conference talk, a heated thread: monorepos are the only sane way to scale, or monorepos are a Google-scale affectation that ruins normal teams. Both sides have scars, both sides have receipts, and the debate never converges.
It never converges because the two sides are rarely arguing about the same thing. Listen closely to someone passionate in this debate and you can usually hear the actual grievance underneath: a CI queue that ate their afternoons, a migration that went badly, a dependency upgrade that took a quarter. The repo structure is the noun in their sentences, but it is rarely the subject of their pain.
So before taking a side, it is worth doing the unglamorous thing: separating what monorepos and polyrepos actually determine from what teams blame them for.
What the complaints are actually about
Take the standard charges against monorepos, one at a time.
"CI is unbearably slow." That is a build system problem. A monorepo without change detection rebuilds the world on every commit, and that is miserable. But affected-only builds, remote caching, and task graphs exist precisely to make CI proportional to the change, not the repo. Slow CI in a monorepo is a missing tooling investment, not a property of the directory layout.
"Nobody knows who owns what." That is an ownership problem, and it is portable. An org that cannot name an owner inside one repo also cannot name one across forty repos; the confusion is just harder to see when it is distributed. Code ownership files, review routing, and clear team boundaries work in both structures and are absent in both structures at struggling companies.
"One team can break everyone." That is an interface discipline problem. Shared code with no contract and no versioning strategy breaks consumers in a monorepo loudly and immediately, or in a polyrepo quietly and three weeks later when someone finally upgrades. The monorepo did not create the coupling. It made the coupling visible on the day it was introduced, which is arguably a favor.
Now run the same exercise on polyrepo complaints. "Every cross-cutting change takes weeks." "Half our repos run a two-year-old version of the shared library." "Nobody can find anything." These are the same three problems, build orchestration, ownership, and interface discipline, expressed in a distributed dialect.
“The monorepo did not create the coupling. It made the coupling visible on the day it was introduced, which is arguably a favor.”
The symptom on the surface
Repo structure is the most visible artifact of how an engineering org works. It is in your terminal every day. It is the thing you clone, the thing whose CI you wait on, the thing whose folder layout you navigate. So when development feels bad, the repo is standing right there, holding the visible end of the problem.
The invisible end is somewhere less satisfying to blame: a build system nobody has owned in two years, a platform team that was never funded, an API between two teams that was never actually designed, just accreted. Fixing those is slow, organizational, and unglamorous. Migrating the repo structure is a project, with a name, a plan, and an end date. Orgs love projects.
Which is how you get the great migration cycle: the polyrepo org drowning in version drift consolidates into a monorepo, feels better for a year because the migration came with fresh tooling investment, then watches CI slow down as the investment lapses, and starts talking about splitting things back out. The structure changed twice. The underlying discipline never did. The improvement each time was the attention, not the architecture.
“The improvement each time was the attention, not the architecture.”
What you are actually choosing
Strip away the misattributed complaints and a real choice remains, because the two structures do genuinely differ in one thing: where the coordination cost lives.
A monorepo concentrates it. Atomic cross-project changes, one dependency version, universal refactoring, at the price of a build and CI system that must scale with the whole org, and a blast radius that requires real tooling to contain. You are buying coherence and paying in infrastructure.
A polyrepo distributes it. Small fast repos, natural isolation, teams that can move independently, at the price of version drift, multi-repo changes that require choreography, and shared standards that must be enforced by process rather than by proximity. You are buying autonomy and paying in coordination.
Neither of these is free, and crucially, both bills are permanent. The choice is not between a structure that has problems and one that does not. It is between which set of problems fits your org: one place where coordination is explicit and loud, or many places where it is implicit and quiet. Small orgs with heavy cross-team collaboration usually suffer less under the monorepo bill. Orgs with genuinely independent products and separate deploy cadences often suffer less under the polyrepo one. That is the whole decision, and it is much smaller than the debate pretends.
The question that reveals your team
Here is what the choice actually reveals, and why the debate stays hot: your answer says what your org is willing to invest in, and what it prefers to pretend is free.
A team choosing a monorepo is claiming it will fund build tooling forever. A team choosing polyrepos is claiming it will maintain interface discipline and dependency hygiene forever. The failures you see in the wild are almost never the structure failing. They are one of those claims quietly turning out to be false.
So if your development experience is bad, the useful diagnostic is not "should we switch repo structures." It is: which claim did we make, and did we keep it? Is CI slow because monorepos are bad, or because nobody owns the build? Is the shared library stale everywhere because polyrepos are bad, or because upgrading was never made anyone's job?
Answer those honestly and one of two things happens. Either you fix the actual problem and the repo debate evaporates, or you discover your org genuinely made the wrong tradeoff for its shape, and now you can migrate for a real reason, with the underlying discipline coming along this time. Both outcomes beat the usual one, which is a two-year migration that relocates the pain and calls it progress.
“The failures you see are almost never the structure failing. They are an investment claim quietly turning out to be false.”