Why Block Took the Monorepo Plunge
Block, the company behind Cash App and Square, has consolidated roughly 450 JVM-based repositories into a single monorepo, a migration detailed in an InfoQ report published June 19. The driver was a problem familiar to any organization running hundreds of services: dependency version drift. When code lives in 450 separate repositories, keeping shared libraries aligned becomes a constant, low-grade tax, and a change that touches multiple services turns into a choreography of coordinated pull requests across teams.
A monorepo collapses that choreography into a single commit. Atomic updates across services become possible, and there is one version of the truth for every shared dependency. That is the theory, and Block's results suggest it largely held. The migration was not a clean-room rewrite, it was an incremental absorption of legacy projects with their own build quirks and performance characteristics, which is precisely what makes the outcome credible rather than aspirational.
The Numbers Behind the Move
The consolidated repository now supports approximately 8,800 builds per week, with P90 CI times sitting around 10 minutes on a stable main branch. Those figures matter because they answer the first objection anyone raises about monorepos: that they grind to a halt as they grow. A P90 of 10 minutes across nearly 9,000 weekly builds is a respectable result for a codebase of this size, and it did not come for free.
Block reached it through dependency-graph-based build scoping, which ensures that a change only triggers the builds it can actually affect rather than the entire repository. This is the single most important technique in any large monorepo. Without it, every commit pays for the whole codebase, and CI times balloon until developers route around the system entirely. With it, the monorepo can scale while keeping feedback loops tight.
The Tooling That Made It Work
The migration leaned on a stack of custom and off-the-shelf tooling. A custom IntelliJ plugin enables selective project loading, so an engineer working on one service does not have to load all 450 into their IDE, a workflow that would be unusable otherwise. Gradle convention plugins define module types and enforce consistency, while merge queues keep the main branch stable by serializing integration and preventing the classic problem of two individually-passing changes breaking when combined.
Block also explored Git performance optimizations, including sparse checkout, to keep clone and working-copy operations fast at scale. This is the unglamorous reality of monorepo engineering: the architecture is only as good as the developer-experience tooling wrapped around it. Strip away the IDE plugin and the build scoping, and the same 450 repositories in one place would be a productivity disaster.
A Step-Change, With a Warning Attached
Gabor Pap, Senior Engineering Manager at Block, summarized the outcome: "What started as a complex migration became a step-change in developer experience with optimized IDE workflow and faster CI." The phrasing is telling. The headline benefit was not raw build speed, it was the qualitative experience of working in a unified codebase where changes propagate atomically and the IDE behaves sensibly.
But the engineers were careful not to sell the monorepo as a universal answer. Yissachar Radcliffe stressed that monorepos require committed platform-team investment and advised against adoption without adequate funding, noting they work best for similarly-structured projects. That caveat is the most useful part of the story for other organizations weighing the same move.
The Lesson for Everyone Else
Block's migration is a strong data point in favor of monorepos at scale, but the implicit precondition is enormous: a funded, dedicated platform team building custom tooling over an extended timeline. The 10-minute P90 and the atomic commits are downstream of that investment, not a property of monorepos in general. An organization that consolidates 450 repositories without the IntelliJ plugin, the build scoping and the merge queues will reproduce the pain, not the payoff.
For enterprise architects, the honest takeaway is that the monorepo-versus-polyrepo debate is less about the topology and more about whether you are willing to staff the platform engineering that makes either work. Block could afford a custom developer-experience effort. The advice to avoid monorepos without adequate funding, coming from the team that just completed one successfully, is the most credible guidance in the entire account.
