The thing most people miss: it's not about the repository structure, it's about whether your organization can actually enforce a shared deployment cadence

I keep seeing this framed as a technical choice, like the answer lives in git or CI/CD tooling. But I worked at a company (mid-2010s) that switched from monorepo to polyrepo specifically because they had twelve teams shipping on different schedules. The monorepo worked fine technically. The problem was that every deploy touched a shared artifact, and you'd get blocking situations where team A's QA window collided with team B's hotfix. Polyrepo solved the human problem, not the technical one. Then we grew to 40 people, deployment chaos got worse, and we moved back. Same tooling. Same people, mostly. Different org structure. The operative variable is whether you've got the social/organizational capacity to make simultaneous changes feel safe. If you can't afford to coordinate, monorepo forces you to pay a real cost in merge conflicts and CI wait times. If you've built the practices—good automated tests, versioning discipline, clear contracts between services—then a monorepo actually reduces the category of surprise failures. But those practices are *hard*. Most companies just don't have them. So polyrepo becomes the path of least resistance: you buy your freedom from coordination by accepting duplication and version skew. What's weird is that people rarely admit this is what they're actually optimizing for. They'll write a technical post about artifact management instead of saying "we chose this because we have six teams who don't talk and we needed them to stop blocking each other." Once you name that variable, the answer gets a lot clearer, and it's specific to your org size and maturity, not universal.