What is a monorepo?

Ten teams, ten code repositories, ten copies of the same function each modified slightly differently: that is what software entropy looks like after a few years of growth. A monorepo proposes the inverse — all of a company’s code, from the website and the mobile app to backend services and shared components, lives in one repository, like a single office building instead of branch offices scattered across a city. A change touching three projects happens in one operation, visible and tested together; shared components have exactly one source of truth, so nobody has to guess which copy is current. Google, Meta and Microsoft work this way at enormous scale, which is where most of today’s tooling came from. For a mid-sized company the topic becomes relevant the moment several products share code: the monorepo removes duplication and friction between teams, but it demands appropriate build tooling — Nx, Turborepo, Bazel and their relatives — and genuine discipline about ownership. Without both, the shared building simply becomes a crowded corridor in which nobody knows whose desk is whose.