Monorepo vs Polyrepo: Repository Strategy for Teams

Repository Strategy Is a Team Decision, Not a Technical One

The monorepo versus polyrepo debate is usually framed as a technical choice: which approach handles dependencies better, which produces faster CI, which scales to more code. But the most important factor in the decision isn't technical — it's organizational. How your team communicates, how ownership is distributed, and how tightly coupled your services are should drive the repository structure, not the other way around.

Google, Facebook, and Twitter use monorepos at massive scale. Netflix, Amazon, and Spotify use polyrepos at massive scale. Both approaches work. The question isn't which is objectively better — it's which one aligns with your team's size, structure, and working style.

I've worked with both approaches across different projects and team sizes, and the patterns for when each works well are clear and predictable.

The Monorepo Case

A monorepo places all related code — services, libraries, configuration, infrastructure — in a single repository. The entire system is visible, searchable, and modifiable in one place.

Atomic cross-cutting changes are the monorepo's strongest advantage. When a shared type definition changes, a database schema evolves, or an internal API contract is updated, the monorepo lets you update every consumer in a single commit. In a polyrepo world, this same change requires coordinated pull requests across multiple repositories, each of which needs to be merged in the correct order. The coordination overhead is real and grows with the number of repositories.

Code sharing without package management. In a monorepo, sharing a utility function or type definition between services is as simple as importing from a relative path. There's no need to publish a package, manage versions, or coordinate upgrades across consumers. For teams that share significant amounts of code between services, this eliminates a category of work that's tedious and error-prone.

Consistent tooling and standards. A single linting configuration, a single TypeScript configuration, a single testing framework applies to everything. New developers learn one set of conventions. Code reviews follow one set of standards. There's no drift between repositories where each gradually develops its own style.

The downsides are equally clear. CI complexity increases because you need to determine which parts of the monorepo changed and run only the relevant tests and builds — otherwise every commit triggers the entire CI pipeline, which becomes unsustainably slow as the repo grows. Tools like Nx, Turborepo, and Bazel solve this with dependency graphs and caching, but they add their own complexity.

Ownership boundaries blur. When everyone can modify everything, it's harder to establish clear ownership. A well-intentioned change to a shared library can break a consumer that the author didn't test. Code ownership files (CODEOWNERS) help but don't fully solve the problem.

The Polyrepo Case

A polyrepo gives each service, library, or application its own repository. Each repo has its own CI pipeline, its own versioning, and its own deploy cycle.

Team autonomy is the polyrepo's strongest advantage. Each team owns their repository completely. They choose their dependencies, set their release schedule, and manage their CI pipeline without affecting anyone else. This independence is valuable for teams that move at different speeds, use different technologies, or operate in different time zones.

Deployment independence is straightforward. Each repository deploys independently, and there's no risk that deploying one service accidentally includes unintended changes to another. The deployment pipeline for each service is simple, focused, and fast.

Access control is simpler. If some code is sensitive — a billing service, a security library — access can be restricted at the repository level without complex directory-level permissions within a monorepo.

The downsides mirror the monorepo's strengths. Cross-cutting changes are expensive. Updating a shared library means publishing a new version, then updating the dependency in every consuming repository, then verifying that each consumer works with the new version. With ten repositories consuming a shared library, a single interface change requires ten coordinated PRs.

Consistency drift is inevitable. Without active effort, repositories develop divergent linting rules, different testing practices, different directory structures, and different dependency versions. A developer moving between repositories loses time adapting to different conventions. Standards documents help, but enforcement requires tooling that's harder to maintain across independent repositories.

Making the Decision for Your Team

Team size is the strongest predictor. Teams under ten developers almost always benefit from a monorepo. The coordination overhead of multiple repositories exceeds the benefit when the team is small enough to communicate directly. Teams over fifty developers often benefit from polyrepos (or multiple smaller monorepos) because the blast radius of changes in a single massive repository becomes unmanageable.

Coupling determines structure. If your services share types, call each other frequently, and evolve together, a monorepo keeps that coupling manageable. If your services are genuinely independent — different tech stacks, different deployment targets, different release cadences — polyrepos reflect and reinforce that independence. Repository boundaries should match architectural boundaries, not create artificial ones.

Tooling investment capacity matters. Monorepos at scale require tooling investment. If you don't have the capacity to set up incremental builds, selective CI, and dependency graph management, a monorepo will slow your team down as it grows. Polyrepos require less sophisticated tooling but more coordination discipline.

A pragmatic middle ground works for many teams: a monorepo for closely related services and shared libraries, with separate repositories for genuinely independent systems. This captures the monorepo's benefits for tightly coupled code while preserving the polyrepo's autonomy for independent projects.

Whatever you choose, document the decision and the reasoning behind it. Repository strategy is an architectural decision that affects every developer on the team, and the "why" behind the choice matters as much as the choice itself. When the team grows and the decision needs to be revisited, that documentation prevents re-litigating the same debates without the original context.

The right repository strategy is the one that reduces friction for your team at your current scale. Don't optimize for Google's problems when you have a ten-person team, and don't maintain ten repositories when a single one would let your small team move faster together.