The case for monorepos.
When one repository is better than many.
Three years ago we split a monorepo into twelve repositories. Last year we moved them back. This is what I learned.
Why we split
The reasons were sensible at the time: independent deploy cadences, team ownership boundaries, smaller CI pipelines. In theory, splitting would give each team autonomy and reduce the blast radius of bad deploys.
What actually happened
Cross-cutting changes became expensive. A simple interface change required four pull requests across three repositories, coordinated in Slack, merged in sequence. Dependency drift became a maintenance burden. The “independent deploys” we wanted required coordination anyway.
What moving back taught us
The tooling has caught up. Turborepo, Nx, and Bazel make large monorepos tractable. Affected-only CI means you don’t pay the full build cost on every change.
The decision isn’t monorepo vs polyrepo. It’s whether your tooling can support the coordination your team actually needs.
The right answer depends on your team’s size, your deployment model, and your tolerance for tooling investment. For teams under fifty engineers shipping a coherent product, the monorepo wins on almost every dimension.