Monorepo vs. multi-repo: a practical decision framework

Few engineering debates generate more heat per unit of practical insight than monorepo vs. multi-repo. Teams have strong opinions. Those opinions are usually formed by their last painful experience — either a multi-repo where coordinating a cross-service change took a week, or a monorepo where a single broken test blocked forty engineers.

Here's a more useful frame: repo structure is a Conway's Law problem. The right repo structure mirrors your team structure. Everything else is tooling.

When monorepos win

Monorepos shine when your teams are highly interdependent — when a change in one package frequently requires changes in another, when you want to enforce consistent tooling and standards across the codebase, and when the cost of version coordination between packages is real and recurring.

Google, Meta, and Microsoft all operate monorepos at a scale that makes the debate seem trivial for most teams. At 50–500 engineers, the main benefit is atomic commits across packages and a single source of truth for dependency versions.

• Atomic cross-package changes — one commit, one PR, one rollback
• Shared tooling, linting, and CI configuration
• No version matrix for internal dependencies
• Easier to enforce architecture rules with tools like Nx or Turborepo

When multi-repo wins

Multi-repo is the right default when your services are independently deployable and genuinely decoupled — when the mobile team should never be blocked by the backend team, when different services need different tech stacks, or when you have a clear service ownership model and want clean blast radius boundaries.

The hidden cost of monorepos at scale is CI time. When everything is in one repo, CI must either test everything on every commit (slow) or implement sophisticated affected-detection logic (complex). Multi-repo keeps CI simple by default.

Pick the structure that reduces coordination cost for your most common type of change. That's it. The rest is preference.

The hybrid approach

Most mature organisations end up somewhere in between: a monorepo for tightly coupled services (often the core product), and separate repos for genuinely independent services (often internal tools, data pipelines, or mobile apps). The seams between repos are usually where your team boundaries are — which is Conway's Law in action.

Don't migrate for migration's sake. If your current structure works and the friction is manageable, the cost of migration rarely pays back in the first year. Migrate when a specific, recurring pain — not a theoretical preference — makes the status quo unsustainable.