The monorepo vs polyrepo debate has consumed significant engineering discussion time. The practical answer is less dramatic than the discourse suggests — both have clear advantages for specific organisational contexts.
What Each Means
Monorepo: all code for all projects/services/packages in a single git repository. Google, Meta, Airbnb, and many large tech companies use this approach. Polyrepo: each service or package has its own repository. The more traditional approach; what most smaller companies default to. The choice affects tooling, dependency management, code sharing, and developer workflow.
Monorepo Advantages
Cross-service refactoring is straightforward — you make a change and update all callers in one commit. Shared libraries are updated atomically — no “which version of shared-utils is this service using?” questions. Visibility: any developer can see and search all code. CI can test the impact of a change across all services that depend on it. Tools like Nx, Turborepo, and Bazel have made large-scale monorepos significantly more manageable by providing incremental builds and affected-only test runs.
Polyrepo Advantages
Independent deployment — each service’s build, test, and deployment pipeline is self-contained. Independent versioning — services can upgrade dependencies at their own pace. Team autonomy — teams own their repository and can set their own conventions. Clearer security boundaries — access to one repository does not imply access to all. For organisations where services are truly independent or where teams operate in relative isolation, polyrepo is simpler.
The Actual Decision
Monorepo works well for: frontend-heavy organisations (Next.js + shared component libraries), organisations where services share substantial code, and organisations with strong platform teams that manage build tooling. Polyrepo works well for: organisations with genuinely independent services, organisations where teams operate autonomously, and organisations where security isolation between services matters. Most organisations would do fine with either — the choice matters less than having consistent tooling and practices within your chosen approach.
