One Repository to Rule Them All? The Hidden Costs of Going Monorepo at Scale

The pitch is compelling. Consolidate every service, library, and configuration file into a single repository. Eliminate dependency drift. Give every engineer visibility into the entire codebase. Ship coordinated changes across teams in a single pull request. On paper, the monorepo is an engineering organization's dream.

In practice, for teams beyond a certain threshold, it frequently becomes something else entirely.

This is not an argument against monorepos as a concept. Google, Meta, and Microsoft have famously operated at monorepo scale for years, and their experiences are well-documented. But those organizations also built custom tooling—Bazel, Buck, and the internal systems that make large-scale single-repository development tractable—that most engineering teams will never have the resources to replicate. The question worth asking is not whether monorepos can work. It is whether they will work for your team, at your current scale, with your existing tooling and culture.

The Seductive Promise of a Single Source of Truth

Monorepos gain traction for legitimate reasons. When services are scattered across dozens of repositories, dependency management becomes a recurring nightmare. Teams fall out of sync. A breaking change in a shared library propagates silently until something downstream fails in production. Onboarding engineers must navigate a sprawl of repositories, each with its own conventions, CI configurations, and access controls.

Consolidating into a monorepo appears to solve all of this. Atomic commits spanning multiple services become possible. Code reuse is structurally encouraged. Visibility improves. For teams in the 10-to-30 engineer range working on tightly coupled systems, these benefits are real and measurable.

The trouble begins when teams carry those assumptions into environments where they no longer hold.

Where Monorepos Begin to Break

Merge Conflict Accumulation

In a distributed repository model, teams operate with natural isolation. A backend services team and a frontend platform team rarely touch the same files. In a monorepo, that boundary dissolves. Shared configuration files, root-level tooling, and cross-cutting infrastructure code become contested territory. As team count grows, so does the frequency of conflicts on files that no individual team owns clearly.

This is not a hypothetical. Engineering teams that have migrated to monorepos consistently report that merge queues—particularly on trunk-based development workflows—become bottlenecks within months of consolidation. A pull request that would have merged in minutes in an isolated repository now waits behind a queue of unrelated changes, all competing for the same validation pipeline.

CI/CD Pipeline Degradation

Build systems optimized for polyrepo structures do not translate cleanly to monorepos. Without sophisticated incremental build tooling, every commit triggers the entire test suite. A one-line documentation fix in a utility library kicks off a full rebuild of every dependent service. Pipeline times that were measured in minutes balloon to hours.

Teams often respond by implementing path-based filtering—only run tests for the affected directories. This is a reasonable stopgap, but it introduces a new class of problem: it becomes possible to ship changes that break downstream consumers without triggering the tests that would catch the failure. The build system's apparent efficiency masks genuine coverage gaps.

Accountability Erosion

Ownership is one of the most underappreciated dimensions of repository architecture. In a polyrepo structure, accountability is structurally enforced. A team owns a repository. They are responsible for its health, its CI status, its dependency updates. The organizational unit and the technical unit are aligned.

Monorepos blur this alignment. When a shared module degrades or a root-level configuration drifts, identifying the responsible party requires organizational archaeology. CODEOWNERS files and directory-level permissions can partially restore this clarity, but they require disciplined maintenance that frequently lapses under delivery pressure. The result is a codebase that technically belongs to everyone and functionally belongs to no one.

The Case Studies Worth Examining

Several mid-sized US technology companies have publicly discussed their experiences with monorepo migrations, and the pattern is instructive. Teams in the 50-to-150 engineer range—large enough to feel polyrepo friction, but not large enough to invest in custom build infrastructure—tend to experience the sharpest pain.

A common trajectory: initial migration produces a genuine productivity boost as dependency management simplifies. Six to twelve months later, CI times have doubled. A year after that, a dedicated platform engineering team is spending the majority of its cycles managing monorepo tooling rather than building product infrastructure. The productivity gains have been consumed by tooling overhead.

This is not a failure of execution. It is a predictable consequence of adopting an architecture that requires investment proportional to scale.

A Framework for the Decision

The monorepo versus polyrepo question does not have a universal answer, but it does have a principled one. Consider the following dimensions before committing to either direction.

Coupling density. If your services share significant amounts of code and change together frequently, a monorepo reduces coordination overhead. If your services are genuinely independent, the shared repository adds friction without benefit.

Build infrastructure maturity. Do you have the tooling to support incremental builds, test impact analysis, and distributed caching? If not, a monorepo will degrade your pipeline performance as the codebase grows. Adopting a monorepo without this infrastructure is borrowing against future engineering capacity.

Team structure. Monorepos work best when team boundaries and directory boundaries are clearly aligned and actively maintained. If your organization lacks the discipline to enforce ownership conventions, consolidation will accelerate accountability erosion rather than resolve it.

Scale trajectory. A monorepo that works well at 40 engineers may be untenable at 200. Build the migration cost into your planning if you anticipate significant headcount growth.

Consolidation Is Not a Strategy

The most important reframe for teams evaluating monorepos is this: repository architecture is an organizational decision, not just a technical one. Consolidating codebases does not resolve the underlying coordination challenges that motivated the migration. It changes the surface area where those challenges appear.

Teams that succeed with monorepos invest heavily in tooling, ownership conventions, and build infrastructure. Teams that treat consolidation as the solution—rather than as a structural choice that enables solutions—tend to find that the problems they hoped to eliminate have simply moved.

Version your decisions as carefully as you version your code. The architecture you choose today will compound, for better or worse, across every commit your team makes for years to come.