At some point in most growing engineering teams, someone opens the repo list and says, "We have 47 repos. Half of them have not been touched in 8 months. Nobody knows who owns what."
That is usually when the word monorepo starts showing up in Slack.
Before you reorganize everything into one giant repository, it is worth talking about what day to day life in a monorepo actually looks like. Some days are great. Some days are messy. Some days CI takes 25 minutes and everyone just waits.
Wait, What Even Is a Monorepo?
A monorepo is exactly what it sounds like: one repository that holds multiple projects. It can include your frontend, backend, mobile app, shared component library, and internal tools in the same place. That is different from a monolith, and it is also different from a polyrepo setup with many separate repositories.
I like to think of it as a neighborhood. Each project has its own space, but everyone shares the same street and the same utilities.
Companies like Google, Meta, and Airbnb have used monorepos at massive scale, but that alone does not mean it is the right choice for your team.
├── apps/
│ ├── web/
│ ├── admin/
│ └── mobile/
├── packages/
│ ├── ui/
│ ├── config/
│ ├── shared-types/
│ └── utils/
├── services/
│ ├── auth/
│ └── billing/
├── tools/
│ └── scripts/
├── package.json
├── pnpm-workspace.yaml
└── turbo.json
Why People Fall in Love With Monorepos
1. Atomic Changes Across Projects
This is usually what wins people over first. Imagine you are renaming a function in your shared utilities package. In a polyrepo world, you change it, publish a new version, then update every repository that depends on it, one PR at a time.
In a monorepo, you change it once, update everything that uses it in the same PR, and ship it together. No version mismatch. No "you are still on the old API" conversation two weeks later.
2. Shared Code Without the Overhead
Creating a shared library in a polyrepo setup has friction. You need a new repository, a publishing pipeline, versioning, and changelog management. It is a lot, so teams often copy and paste code instead.
In a monorepo, sharing code is almost too easy. You just import it. That low friction is great for building consistent patterns across your codebase.
3. One Place to Look
When a new developer joins the team, they clone one repository. They can see how the frontend talks to the backend, how auth works, and what the shared types look like. Onboarding gets easier when the whole picture is in one place.
4. Unified Tooling and Standards
Linting rules, TypeScript configs, and testing setups can be defined once, and every project inherits them. Enforcing standards gets easier when you are not playing whack a mole across dozens of repositories.
Why Monorepos Can Make You Want to Cry
1. CI/CD Becomes Your Nemesis
This is the big one. In a regular repository, you push a change, run tests, and move on. In a monorepo, a naive setup runs everything for every change, even if you only touched a CSS file in one component.
Getting CI to run only what is affected is possible, but it takes real effort. Tools like Turborepo, Nx, or Bazel help a lot, but they add complexity and a learning curve.
Until you invest in that infrastructure, your developers will spend a lot of time waiting.
2. Git Gets Slower
Once a monorepo has years of history and millions of files, basic Git operations start to feel slow. Cloning the repository, running git log, and even tab completing paths all get heavier.
There are solutions (shallow clones, sparse checkouts, git partial clone), but it is still extra complexity you did not have before.
3. Ownership Gets Blurry
"Who owns this?" becomes a common question. When everything lives together, boundaries between teams can blur. Someone touches a shared utility to fix one bug and accidentally breaks three other teams.
This is where CODEOWNERS becomes essential. Clear ownership documentation matters more than most people expect.
4. The "One Repo" Illusion
A monorepo does not mean your architecture is clean. It does not magically enforce good boundaries between services. Teams sometimes move to a monorepo hoping it will solve deeper organizational problems. It will not. If your codebase is messy, a monorepo is that same mess in one place instead of many places.
The Everyday Realities Nobody Warns You About
Merge conflicts hit harder. When 50 engineers are committing to the same repository, merge conflicts on shared files (like package.json or lockfiles) become a daily experience. You will quickly develop strong opinions about lockfile strategies.
Your IDE will struggle. Opening a monorepo in VS Code or IntelliJ on a lower spec machine can be rough. Indexing can take forever. Language servers get confused. You spend time tuning workspace settings just to keep things usable.
Dependency management gets tricky. Shared dependencies are great until different packages need different versions of the same library. Handling version conflicts across a monorepo requires discipline and sometimes painful tradeoffs.
The initial migration is painful. If you are moving from a polyrepo setup, this is not a weekend project. It is usually a multi week effort that includes rewriting CI pipelines, updating import paths, convincing teams to change workflows, and deciding how to handle Git history.
Should You Use a Monorepo?
Here is the honest answer: it depends, and the decision is usually more organizational than technical.
In my experience, it depends a lot on the product you are building and how teams interact with each other. A monorepo can be a great solution when teams are well integrated and their work depends deeply on one another. But if each team needs clear ownership of its code and wants a simpler development and release flow without constantly tracking changes from other teams, a monorepo might not be the best choice.
Go monorepo if:
- You have multiple projects that share a lot of code or types
- Your teams work closely together and frequently ship changes across project boundaries
- You're willing to invest in proper tooling (task runners, affected-only CI, etc.)
- You have a culture of shared ownership and good code hygiene
Stick with polyrepos if:
- Your projects are genuinely independent and rarely interact
- Your teams are siloed and work autonomously with different release cadences
- You don't have the bandwidth to invest in monorepo tooling right now
- Your organization is still early-stage and things change dramatically week to week
The Real Takeaway
A monorepo is not a silver bullet. It is a tradeoff. You trade repository sprawl and versioning headaches for CI complexity and heavier tooling requirements. Neither side is free.
The teams that do well in monorepos treat the repository itself as a product. They invest in developer experience, keep ownership clear, and set up smart build tooling instead of hoping a naive setup will scale.
If you go in expecting magic, you will be disappointed. If you go in with open eyes and a plan for the hard parts, it can make collaboration much smoother.
Good luck. May your CI be fast and your merge conflicts be few.
Have thoughts on this? Disagree entirely? Both are valid. Monorepo opinions run hot.
