The actual operative variable is coordination cost, and people keep arguing about the wrong thing

I watched a team at my last job spend three months evaluating monorepo tooling. They read the Google paper, looked at Uber's blog post, kicked the tires on Nx and Bazel. What they actually needed was a decision about how often they'd let their payment service and their web client drift out of sync with each other. They never framed it that way. They framed it as "should we have one repo or many." The answer to the repo question was downstream of the answer to the drift question, but everyone treats it as primary. The reason this debate doesn't converge is that both sides are describing *situations where they were right*. Google runs a monorepo because coordinating changes across thousands of services without atomic cross-service commits would be a nightmare at their scale. They solved a real problem. But I've also seen startups with five services where the monorepo became a commit-permission bottleneck, because deploys had to serialize through shared CI and one team's flaky tests blocked another team's releases. Different problem, same tool, opposite outcome. The operative variable is how tightly coupled your services need to be at the source level. Not in theory. In practice, on your current deployment model, with your current team size and velocity. If you have hard requirements for synchronized releases, or if schema changes must propagate atomically, you probably want a monorepo. If your services can deploy independently and your contracts are durable, polyrepo friction is mostly overhead. The technology (Git, build systems, CI) barely matters compared to that. But nobody actually makes the decision that way. They make it based on where they happen to work, then rationalize backward.