What is a Monorepo?

Where the idea proved itself

Google is the canonical proof of concept. Their internal monorepo, "Piper," holds roughly two billion lines of code across nearly every Google product, with tens of thousands of engineers committing daily. Meta runs a similar single repository for most of its code. Microsoft, Uber, Twitter, and Stripe have all built or adopted custom tooling to keep large engineering organizations inside a single repo. The pattern works at extreme scale — but it works only with deliberate tooling, not with stock git.

Why teams choose a monorepo

The dominant reason is atomic refactoring. When a shared utility library changes, you can update the library and every caller in one commit, run one test suite, and ship the change as one release. In a multi-repo world the same change is a coordination project — bump version, publish, wait, open a PR in each consumer, hope nobody is on the old version. The cost difference shows up the first time you try to rename a critical method.

Secondary reasons matter too: a single source of truth for tooling, a single CI configuration that everyone benefits from, easier code search across the whole company, and the cultural effect of every engineer being able to read any other team's code without a credential dance.

The tooling problem

Stock git was designed for repositories with a few thousand files; it gets slow around a million and painful past that. Stock CI runs the whole test suite on every commit, which is fine in a small repo and catastrophic in a large one. Modern monorepo tooling — Nx and Turborepo in the JavaScript world, Bazel and Pants for polyglot teams, Buck for very large internal monorepos — solves the same set of problems: only build what changed, only test what changed, share artifacts across CI runs, and prune the work that did not need to happen.

When a monorepo is the wrong choice

If the projects in question are completely independent (separate products, separate companies, separate languages, no shared code), the upside of a monorepo collapses. If the team lacks the discipline to enforce module boundaries inside the repo, the result is a tangled mess that gets blamed on the monorepo when the actual problem is "we let everything import everything." And if the deployment infrastructure forces per-repo release pipelines, you may spend more effort fighting the deployment tooling than you save in refactor velocity.

At QUANT LAB

We default to monorepos for most of our SaaS platforms and custom business software builds — a single repo holding the Next.js app, the backend API, any worker services, shared TypeScript types, design tokens, and the marketing site. Turborepo handles incremental builds; the deployment pipeline is set up so that pushing the marketing site does not rebuild the backend.

For very small teams or pure single-app products, a monorepo would be over-engineered — a plain Next.js app is its own monorepo in miniature. The threshold where we recommend reaching for explicit tooling like Turborepo or Nx is usually three or four distinct deployables. Read our platform engineering guide for the broader picture, or book a call for a one-hour repo-strategy review.