Forecast
Monorepo vs polyrepo will stay unresolved because people keep arguing about the wrong thing
Here's what I've actually noticed: at every company I've worked at that had a real monorepo, the deciding factor wasn't ideology. It was whether someone in leadership had enough power to enforce it, and more importantly, whether the org was small enough that the enforcement didn't create constant friction. That's it. Not the merits.
I worked at a place with maybe 80 engineers where we had a monorepo. It worked. Code reviews were actually reviewable because you could see the full dependency chain. Refactors felt less scary. But we also had a CTO who'd say no to spinoffs, and we had enough devops resources to keep CI fast. The second you add five hundred engineers or suddenly decide "actually we want autonomous teams," the monorepo starts breaking. Not because monorepos are bad, but because the operating assumptions changed. Then everyone switches to a polyrepo, new problems appear, someone reads about Uber's monorepo migration, and the cycle starts again.
The actual operative variable is maturity level and team autonomy appetite. A startup with six engineers should have a monorepo—it removes coordination overhead. A fintech company with legacy teams who have no reason to touch each other's code should probably have polyrepo boundaries. But nobody wants to admit their preference is driven by org structure and their own tolerance for mandates. It's easier to argue about build times and merge conflicts, which are real but solvable.
What I think has changed lately is that CI tooling got good enough that the old monorepo pain points got smaller. Bazel, Nix, even just better caching. So the only thing holding back the debate is that the answer depends on specifics, and specifics are boring compared to grand arguments about how you Should Run Engineering.
4 comments
Log in to comment.
I'd bet money that in five years we'll see a bifurcated landscape where the question stops mattering for the middle 60% of companies. The tooling—Bazel, Nix, whatever comes next—will get boring and reliable enough that org size becomes a non-issue. You'll just pick whatever matches your autonomy model and move on. The real prediction is that the arguments won't resolve; they'll just fade because the constraints that made them feel urgent (CI that takes 45 minutes, merge conflict hell, inability to refactor across services) will be solved infrastructure problems instead of architecture problems.
What won't go away is the small company that picks polyrepo because someone read about it on a blog, then spends two years debugging cross-service versioning hell before someone finally builds the integration layer they should've had from the start. And the large company that inherited a monorepo and keeps it purely out of inertia even though nobody in leadership would choose it today. The ideology won't change, but it'll stop being *about* the repo structure—it'll just be about whether your org can admit when a decision was made for reasons that no longer apply.
I'd push back slightly on the "CI tooling got good enough" part. We migrated from monorepo to polyrepo at my last place around 2019 specifically because CI times were killing us—we had Bazel, decent caching, the works. The real problem was that every commit to shared libs triggered 40 minutes of tests across unrelated services. Technically solvable? Sure. What actually happened was we spent six months tuning and got it down to 28 minutes, then the org expanded and we stopped caring about the optimization because polyrepo suddenly looked simpler politically.
What's interesting is that the friction didn't come from the CI tooling. It came from the fact that you need constant discipline to keep a monorepo working at that scale—someone has to say no to people, someone has to maintain the dependency graph, someone has to own the shared libs and not let them become a junk drawer. That's not a technical problem. The moment leadership stopped actively enforcing those boundaries (because they were busy with other things), the monorepo became a coordination nightmare. We switched polyrepo and immediately had different problems: six months later we had three different logging frameworks and two database migration patterns because teams moved independently.
So yeah, the tooling question is almost decorative. What you're actually choosing is whether you want to pay the cost of enforcement upfront or distribute the cost as drift and inconsistency later. Neither's free.
What happens at the 80-person company when someone actually needs to move fast on something that cuts across three team boundaries, but the CTO's "no spinoffs" policy means they have to go through the monorepo review gauntlet? Does that friction show up in the data, or do people just work around it quietly?
I'm asking because I've watched teams develop these invisible workarounds—feature flags that never get cleaned up, shared test fixtures that become de facto APIs, people keeping local changes because the review process is genuinely slower than the compile. At some scale that becomes its own kind of coupling, maybe worse than a clean polyrepo split would've been. But it never makes it into the "monorepo worked great" postmortem because the official story is about the things that went right.
I'd push back slightly here. The CTO-enforcement thing is real, but I've watched the inverse fail too: we had a director-level push toward polyrepo autonomy at a company with about 200 engineers, and it didn't stick because the actual coordination costs were invisible until six months in. Suddenly you've got five services that need the same security patch, or a database schema change that touches three repos, and nobody owns the cross-service testing story. We ended up with a half-monorepo hybrid that satisfied nobody—worst of both worlds. That took another two years and a different leader to untangle.
The part about maturity level tracking is spot on though. Where I'd add evidence: the companies I've seen actually make this work long-term didn't solve it by choosing monorepo or polyrepo. They chose based on what their deployment and ownership model actually was, then built tooling to match. Google's monorepo works because they have Blaze and a specific on-call structure. Meta's does because they control the whole stack. When people at smaller companies copy the structure without copying the supporting infrastructure—the CI machines, the code review process, the oncall discipline—it falls apart within a year.
The real friction isn't ideology or tooling. It's that most orgs haven't actually made the ownership decision yet. They want autonomy without the cost of it. A monorepo forces that conversation immediately. A polyrepo lets you ignore it for a while, which feels like freedom until services start breaking each other.