When I started building projects from scratch, I kept running into the same question over and over again:
Should I use a monorepo or split everything into multiple repositories?
For a long time, I thought I had a clear answer. Now I'm not so sure anymore.
This is not a theoretical comparison. It's just how my opinion changed after working on real systems with real teams.
At the beginning of my career, I loved monorepos.
They felt simple and natural, especially when I was working alone or in a small team. Everything was in one place, and I didn't have to think too much about boundaries or versioning.
I could change the frontend, update the backend, fix the tests, and ship everything in a single commit. One change, one result. No coordination, no compatibility concerns, no overhead.
At some point I even started wondering why people bothered with multiple repositories at all. It felt like unnecessary complexity.
That illusion didn't last.
The first time my perspective really shifted was when I was leading a team working on micro-frontends for a large product.
There were multiple teams involved. Each team owned a part of the system. Our team was responsible for shared components that were used across many different websites.
Versioning actually mattered there. Not every consumer could instantly adapt to changes, so we had changelogs, migration guides, and some level of discipline around releases.
But everything still lived in one big monorepo.
One morning we came in and the system was broken. Not partially - completely unusable.
After digging through the commit history, I found the cause. A developer from another team had modified one of our shared components to make it work with their API changes. No discussion, no version bump, just a direct change.
We rolled it back and talked to the team. It seemed like a one-off mistake.
It wasn't.
The same thing happened again later, with a different developer.
That's when it clicked for me. In a monorepo, ownership becomes blurry. Even if you define boundaries, the repository itself communicates something else: “this is all one project.”
And once people start thinking that way, they feel allowed to change things outside their domain.
The second time I started questioning monorepos was because of CI.
We had a fairly large codebase, all inside a single repository. To save costs, we were running CI on a relatively weak machine. Every push triggered a complex pipeline, and every pull request depended on it.
At first it was fine. Then the project grew.
Builds became slower. Pipelines became harder to understand. A single change could trigger a chain of checks that had nothing to do with what you actually modified.
We tried to optimize it. Running tests only when certain parts changed, splitting steps, tweaking configurations.
It helped, but only up to a point. There were still global checks — linting, shared validations — that kept everything tied together.
The result was friction. Waiting for CI became part of the development process.
And that's the moment when "convenience" starts turning into "cost".
Today my view is much simpler and much less dogmatic.
If I'm working alone, or with a small team, and the product is evolving quickly without strict requirements for backward compatibility, I would still choose a monorepo. It's fast, it's convenient, and it removes a lot of overhead.
But as soon as multiple teams are involved, or different parts of the system need independent lifecycles, I would split things into separate repositories without hesitation.
Not because it's cleaner in theory, but because it enforces boundaries in practice.
What worked best for me recently is a hybrid approach.
Keeping closely related pieces together makes sense. For example, a frontend app and its UI library can live in one repository. The same goes for a group of tightly coupled backend services.
But mixing everything — frontend, backend, infrastructure — into a single repo just because it's "easier" is something I would avoid now.
It usually is easier at the beginning. And much harder later.
The funny thing is, choosing between monorepo and multirepo is just a small part of a much bigger picture.
What actually makes or breaks a project in production has very little to do with where your code lives.
It's everything around it: CI/CD, migrations, observability, error handling, release processes, and how your team works with all of that.
That's exactly why I started putting together an open-source project where I document how backend systems should actually be built and shipped if you treat them like real production systems from day one.
Not as a boilerplate, but as a walkthrough of decisions — what happens before code, around code, and after code.
If that's something you're interested in, you can check it out here:
https://github.com/prod-forge/backend
There's no universally correct choice between monorepo and multirepo.
There's only context.
And over time, I've learned that good engineering is less about picking the "right" pattern, and more about understanding when your current choice stops working.
Top comments (0)