What's a Monorepo?

A monorepo is a single Git repository that contains multiple projects or services—sometimes dozens or hundreds of them. Think Google's internal codebase (used to manage Android, Search, Cloud, and more), or Meta's Codebase with millions of lines across dozens of products. The opposite is a multi-repo setup: each project gets its own repository.

The term itself is deceptively simple, but the choice between the two shapes your entire workflow: how you code review, CI/CD speeds, access control, and even how your team collaborates.

The Real Benefits of a Monorepo

Atomic Changes Across Projects

The biggest monorepo win: when service A needs to change its API and service B needs to consume that API simultaneously, you commit both changes in one atomic transaction. No race condition where B merges before A. No "we'll fix this in the next sprint." This beats the multi-repo world, where coordinating cross-service changes requires two PRs, two merges, and vigilant humans watching the clock.

Example: Your backend API adds a new field to a response. Your frontend web app and mobile app both need to consume it. In a monorepo, all three changes land together. In multi-repo, you hope the backend PR merges before the frontend PRs, or you have a broken main branch temporarily.

Shared Tooling and Dependencies

One .eslintrc, one prettier.config, one monorepo-wide testing setup. Developers don't debate tool versions per repo; they inherit consistency. A upgrade to Jest or TypeScript happens once, affecting everything. Security patches in shared libraries roll out uniformly.

Multi-repo means each project maintains its own tooling—and developers spend time on "should we upgrade?" conversations per repo.

Easier Refactoring

Moving code between services, extracting shared logic, consolidating duplicate utilities—these are commits in a monorepo. In multi-repo, they become multi-PR coordination exercises. For codebases that evolve rapidly (startups, fast-moving teams), this friction compounds.

Clear Dependency Graph

With tools like Nx or Turborepo, a monorepo maps exactly which service depends on what. You know the impact before you push. Multi-repo leaves developers guessing.

The Real Costs of a Monorepo

CI/CD Complexity and Slowness

The monorepo's size becomes its burden. A single character change in a rarely-used module can, naively, trigger tests for your entire codebase. A 50-service monorepo testing everything on every push is slow and expensive.

This is solvable (differential testing, build caching with Nx, Bazel, or Buck), but it requires investment. Small teams often skip it and suffer 20+ minute builds.

Tooling Overhead

Monorepos demand specialized tooling. Nx, Bazel, Turborepo, Lerna—these are powerful but steep to learn and maintain. A small team of four might not need them; a team of 40 absolutely does. Miss the investment window, and your monorepo becomes a slow, confusing morass.

Access Control Headaches

In multi-repo, you can grant Engineer X access to the mobile app but not the billing service. In a monorepo, they typically get the whole codebase (or none of it). Fine-grained access requires custom scripting or a second layer of permission checks in CI.

This matters for security-conscious teams and large organizations. A junior developer with access to production payment code is a governance nightmare.

Merge Conflicts at Scale

Twenty developers committing across dozens of projects in one repo means more branches in flight. More parallel changes means more conflicts, especially in shared config files or version directories. Multi-repo reduces the collision surface.

The Checklist: Which Should You Choose?

Choose Monorepo If:

  • Small to medium team (2–30 people) with a tightly-coupled product (a web app + backend + mobile all serving the same user base).
  • Frequent cross-service changes are normal (e.g., backend API changes drive frontend updates).
  • Shared infrastructure or components are central to your product (design system, auth library, data models).
  • You're willing to invest in tooling (even a modest setup with Nx or Turborepo).
  • You control access (internal team; security requirements are light).

Real example: A five-person startup building a SaaS product (React frontend, Node backend, shared utilities). One monorepo with Nx keeps everyone aligned, changes atomic, and tooling consistent.

Choose Multi-Repo If:

  • Large, distributed team (50+ engineers) or multiple independent teams with different priorities.
  • Loosely-coupled services (e.g., a backend service owned by team A, an analytics service owned by team B, neither depending on the other much).
  • You have fine-grained access control needs (junior devs shouldn't see production infrastructure; partners need limited access to public APIs).
  • Services have vastly different tech stacks (one service in Python, another in Go, another in Node; each team owns its stack and its repo).
  • Maturity and isolation matter more than atomic changes (e.g., you're managing microservices that are independently deployable and independently versioned).

Real example: A mature fintech company with ten services (payments, KYC, settlement, dashboard, mobile). Each team owns their service's repo. Cross-service communication happens via APIs. Breaking the payments service doesn't require re-testing the dashboard.

Hybrid Approach: Monorepo of Monorepos

Many organizations don't choose one or the other absolutely. Instead, they use a monorepo per team or product area. Your frontend team maintains one monorepo (web, mobile, shared components). Your backend team maintains another (API service, worker service, shared libraries). The two monorepos communicate over APIs or shared private packages.

This gives you atomic changes and shared tooling within a team, while keeping teams decoupled and preventing one team's chaos from infecting another. It scales better than a single monorepo at 500+ engineers, and it's simpler than strict multi-repo if you still have shared infrastructure.

Bottom Line

Monorepos aren't inherently better or worse—they're a trade-off. They buy you atomic changes, consistency, and ease of refactoring at the cost of CI complexity and tooling overhead. For small, fast-moving teams building a tightly-integrated product, they're a productivity win. For large organizations with independent services and security boundaries, they become a liability.

Start with your team size and product shape. Ask: "Will we frequently make changes across multiple services together?" If yes, lean monorepo. If services are truly independent, multi-repo keeps things simple. And if you're unsure, a hybrid approach (monorepo per team) splits the difference and often wins in practice.

The best choice is the one that lets your team move fast without fighting their tools.

Related: still deciding the app itself? See Native, Web, or Hybrid: Choosing How to Build Your App.