From Sprawl to a Single Codebase
Block has merged roughly 450 JVM repositories into a single monorepo, a consolidation that ranks among the more ambitious repository migrations to be discussed publicly. The scale alone makes it instructive: this is not a greenfield experiment but a large, established estate of Java and Kotlin code brought under one roof. For engineering leaders weighing their own repository strategy, Block's account is a rare look at what the destination actually looks like once the dust settles.
The motivation was not novelty but pain. Block's polyrepo setup had reached a point where coordinating changes across hundreds of repositories was actively slowing the organization down. The migration was framed not as a purist architectural preference but as a response to a concrete and worsening operational problem, which is the right way for executives to think about any structural change of this magnitude.
The Dependency Drift Problem
The core issue was dependency management. Yissachar Radcliffe of Block is blunt about it: "Dependency management in the polyrepo had become unmanageable. We were constantly dealing with breaking changes, which sometimes manifested as runtime failures." That last clause is the part technology leaders should sit with, because dependency drift that surfaces as runtime failures is the most expensive kind, escaping every earlier line of defense to fail in production.
In a polyrepo world, every repository pins its own versions, and keeping hundreds of them consistent becomes a coordination problem that grows non-linearly with scale. A single shared codebase changes the math entirely, because one version of a dependency serves the whole tree and a breaking change is caught the moment it lands rather than discovered weeks later in some downstream service. Tackling drift was the central justification for the entire effort.
Engineering the Monorepo at Scale
Making a monorepo work at this scale is a serious engineering undertaking, and Block leaned on several well-chosen techniques. Gradle convention plugins standardize module types so that thousands of modules behave consistently, while merge queues keep the main branch stable by serializing and validating changes before they land. These are the mechanisms that prevent a shared codebase from collapsing under the weight of concurrent changes.
Performance came from dependency-graph-based build scoping, which limits work to only what a change actually affects, and from Git performance tuning such as sparse checkouts so developers do not have to materialize the entire repository locally. The results are concrete: the monorepo supports about 8,800 builds per week with p90 CI times of around 10 minutes on a stable main branch. Those numbers matter because they show a monorepo can be fast and stable at scale when the supporting machinery is built deliberately.
Developer Experience and Open Source
Beyond raw throughput, Block frames the outcome as a developer experience win. Gabor Pap, Senior Engineering Manager at Block, describes the result this way: "What started as a complex, large-scale migration became a step-change in developer experience: a modern, cohesive codebase with an optimized IDE workflow, dramatically faster CI, and a foundation built for long-term velocity." The emphasis on a cohesive codebase and an optimized IDE workflow is telling, because consolidation often improves consistency in ways that are hard to quantify but felt daily.
To support that IDE workflow, Block open-sourced a custom IntelliJ plugin, available at github.com/block/gradle-monorepo-ij-plugin. Releasing internal tooling is a useful signal of confidence, and it gives other organizations a concrete starting point rather than a war story. It also underlines that a monorepo of this size cannot rely on off-the-shelf IDE behavior; the editor experience itself has to be engineered.
The Real Deciding Factor
The most important lesson Block offers is not technical but organizational. Radcliffe puts the trade-off in stark terms: "If you can't commit to properly funding a platform team to support a monorepo, you'll probably do better with a polyrepo." This reframes the entire monorepo versus polyrepo debate away from architectural ideology and toward a question of sustained investment.
We strongly endorse that framing. A monorepo is not a free lunch that eliminates dependency pain; it relocates that pain into platform infrastructure that must be continuously maintained by a dedicated team. Organizations that adopt a monorepo expecting it to run itself will recreate their old problems in a new shape. The architecture you can actually fund and staff is the architecture you should choose, and that calculus should precede any decision about repository structure.
What CTOs Should Take Away
For technology executives, Block's migration is a case study in matching ambition to capacity. The 8,800 builds per week and roughly 10-minute p90 CI times are impressive, but they are the output of a deliberately funded platform investment, not an inherent property of monorepos. The headline metrics should be read alongside the staffing and tooling commitment that produced them.
The actionable guidance is to start with an honest assessment of your platform engineering capacity before debating repository structure at all. If you can commit to a strong, well-funded platform team, a monorepo can deliver the consistency and velocity Block describes. If you cannot, the polyrepo model may genuinely serve you better, and recognizing that constraint up front is far cheaper than discovering it halfway through a 450-repository migration.
