What is a Monorepo, and Why Does it Matter?

A monorepo is less a vault for code and more a city where it all lives. In the old world, projects sat in scattered villages, each with its own fences and dialects. Bring them together and suddenly you have streets that connect, buildings that share foundations, and neighbours who can see what each other are building. Standards don’t arrive by decree. They appear the way traffic lights do, because the city needs them to flow.

Most people hear “monorepo” and think only of code. In reality, a monorepo is as much about people as it is about software. It changes how we see each other, how we collaborate, and how we imagine the future of building things together. “Monolithic repository” is a misleading label. It doesn’t mean a giant, immovable block of code. It means one place where all of a company’s projects live side by side. And in that place, people begin to meet.

Breaking Down Walls

When you move to a monorepo, the first thing you notice is how silos start to crumble. Engineers who might never have seen each other’s code suddenly inhabit the same space. Standards begin to emerge, not because of mandates, but because visibility creates accountability.

A bug fixed in one corner can ripple across the company. A better way of writing tests, or enforcing security checks, spreads almost instantly.

It becomes less about my repo and more about our codebase. The repository itself becomes a town square: a shared place of contribution, conversation, and responsibility.

Standards as Shared Language

Consistency is rarely glamorous, but it is powerful. A monorepo makes it easier to apply the same rules everywhere: style guides, dependency policies, security scans, even the way we name our branches.

These things may seem small in isolation, but together they form a language — a way of working that feels coherent across teams.

And when standards live in one place, they evolve faster. You change a rule once, and the effect is felt everywhere. Instead of wrestling with drift, you get momentum.

Preparing for the Future

There’s another reason monorepos matter, and it has less to do with humans and more to do with the systems we are beginning to work alongside.

AI thrives on context. The more of the codebase it can see, the better it can suggest changes, detect patterns, and make improvements that stretch across the product, not just within a single service.

Imagine migrating an API, or introducing a new accessibility guideline. In a world of separate repositories, this becomes a patchwork project: chasing down each codebase, negotiating local quirks, and hoping nothing slips through the cracks.

In a monorepo, it’s one change, one sweep, one coherent transformation — with AI agents soon able to automate much of the work.

Holistic visibility enables holistic improvement.

Myths and Misunderstandings

Whenever the idea of a monorepo is raised, familiar worries surface. Some hear the word and immediately picture a giant monolith — one fragile block of code where everything is tied together. But a monorepo is about source, not runtime. The code may live together, but services, apps, and products still deploy independently, on their own schedules, with their own pipelines.

Others fear that builds will grind to a halt. Yet build speed is not dictated by folder structure in Git; it is shaped by the tools we choose and the way our CI/CD is orchestrated. With caching, incremental builds, and path-based triggers, feedback loops can remain just as fast — and in many cases, faster.

Release cadence often comes up too. Web teams want to ship daily, while backend or platform teams might move more deliberately. A monorepo doesn’t flatten those differences; it simply makes them visible. A change to one folder needn’t ripple into another. Teams can, and should, continue to release at the pace that suits their product.

Permissions are another common worry: the fear that a monorepo is a free-for-all, where anyone can change anything. In practice, the opposite is true. With code owners and protected branches, review boundaries become sharper, not blurrier. Sports approves Sports, Payments approves Payments. Visibility increases, but authority remains local.

And then there’s the size of it all. Won’t the repository balloon until it becomes unmanageable? In truth, modern Git offers mirrors, partial clones, and shallow checkouts to keep day-to-day developer experience light. Heavy assets belong in registries, not wedged into source control. Good hygiene goes further than fragmentation ever could.

What these myths share is the belief that a monorepo changes how you build and release. It doesn’t. It changes where the code lives. And in doing so, it creates the possibility of working as one organisation, not a collection of silos.

Proven at Scale

This isn’t a fringe idea. Some of the most accomplished engineering organisations in the world — Google, Meta, Microsoft, Uber — run on monorepos.

They’ve shown that it’s possible not only to manage complexity at this scale, but to turn it into an advantage. If they can orchestrate billions of lines of code this way, we can draw confidence that the model is robust, not an experiment.

One Codebase, One Company

A monorepo is not just a strategy for source control. It’s a philosophy of collaboration.

One codebase, one company. Shared responsibility for shared assets. A foundation that lets us move faster, not by running alone, but by improving together.

When we work in a monorepo, we stop optimising for the smallest unit — the individual repository — and start building for the whole.

And in that shift, something powerful happens: we begin to see ourselves not as separate teams, but as one organisation, with one product, moving in one direction.