The Appeal of the Monorepo

The Appeal of the Monorepo

All code in one repository. Atomic changes that touch multiple packages. Internal dependencies always in sync. Trivial code reuse.

It sounds elegant. And for teams that need it, it is.

Why It Works for the Big Players

Google has internal tooling developed over decades. Thousands of engineers have refined build, testing, and deploy systems specifically for their scale.

When Google says monorepo works, they're talking about their monorepo with their tooling. Not the same concept applied with generic tools.

The Reality of Public Tooling

Turborepo, Nx, Lerna, pnpm workspaces. There are many options, and each has tradeoffs.

Setting up a functional monorepo requires significant effort. Build complexity increases. CI/CD needs optimizations to avoid running everything on every commit.

For a small team, that overhead can outweigh the benefits.

When Monorepo Adds Value

Multiple applications that share significant code. An internal SDK, UI components, common business logic. If you're copying code between repos, monorepo eliminates that duplication.

Frequent changes that cross package boundaries. If every feature requires modifying three repos and coordinating releases, monorepo simplifies the workflow.

A team that works across the entire stack. If the same people touch frontend, backend, and shared libraries, monorepo reduces friction.

When Monorepo Adds Complexity Without Value

Independent projects that happen to belong to the same organization. A blog and an e-commerce app don't need to be together.

Separate teams with different release cycles. The benefit of atomic changes disappears if teams don't coordinate.

Projects with very different technical stacks. A Go backend and a TypeScript frontend share little. Monorepo doesn't provide reuse.

The Testing Problem

In a monorepo, a change in a shared package can affect everything that depends on it. Testing systems must be smart enough to detect what to test.

Without that tooling, every change runs all tests. Or worse, it doesn't run the necessary tests and bugs reach production.

The Pragmatic Alternative

Separate repos with published packages. More ceremony to update shared dependencies, but less tooling complexity.

For small teams, the friction of maintaining versions may be less than the friction of setting up and maintaining a monorepo.

The Right Question

It's not "should I use monorepo?". It's "what problems do I have and does monorepo solve them better than the alternatives?".

If the answer is honest, many teams would discover that their real problems aren't the ones monorepo solves.