Monorepo vs Polyrepo for a Small Team, What We Actually Chose and Why

Hot take: almost every monorepo vs polyrepo blog post is secretly about problems a five-person team doesn't have. Atomic cross-package commits, unified CI at scale, Bazel-style build graphs, code ownership across forty squads — real concerns, for a two-hundred-engineer org. For a small team, the decision should be made on completely different criteria, and most teams I've advised were about to make it for the wrong reasons.

What small teams actually feel day to day

A five-engineer team I worked with was building a frontend, a backend API, and two internal tooling scripts, split across four repos, and their actual daily pain wasn't anything the monorepo literature talks about. It was: a backend API change and its corresponding frontend change needed to ship together, and reviewing them as two separate PRs in two separate repos, with no enforced link between them, meant they occasionally got merged out of order and briefly broke staging. That's not a build-graph problem. That's a 'these two things are actually one unit of change' problem.

The question isn't monorepo vs polyrepo in the abstract. It's whether your team's actual changes cross repo boundaries constantly, or whether they almost never do.

What we chose and why

We merged the frontend and backend into one monorepo, keeping the two internal tooling scripts in their own separate, small repos. The deciding factor wasn't tooling sophistication — we didn't need Nx or Turborepo's caching machinery at this scale, a plain npm workspace setup with two packages covered it entirely. The deciding factor was that the frontend and backend changed together constantly, while the tooling scripts changed on their own schedule and had zero coupling to the app's release cycle.

• Merge into a monorepo when two codebases' changes are frequently coupled — same PR conceptually, artificially split across repo boundaries today.
• Keep things separate when they have genuinely independent release cycles, different access-control needs, or different teams/clients who should never see each other's code.
• Don't adopt monorepo tooling (build graphs, remote caching, affected-project detection) until you're actually CI-bottlenecked by it — a five-person team's full test suite running in three minutes doesn't need that machinery yet.
• Revisit the decision when team size or repo count roughly doubles — the right answer at five engineers is not a permanent answer, it's the right answer for the problems you have right now.

The staging breakage from out-of-order merges stopped entirely once frontend and backend changes could be reviewed and merged as a single PR. We didn't get there by reading the monorepo-at-scale case studies — we got there by writing down what was actually breaking weekly and picking the structure that fixed that specific thing, which turned out to be a much smaller decision than the online debate makes it sound.