The monorepo wasn't the problem. The reasons we adopted it were. A note on cargo-culting other people's constraints.
We adopted a monorepo because the companies we admired had one. That's a terrible reason, and it took us a year to admit it. Their constraints — thousands of engineers, shared infra at scale — were nothing like ours.
01 — The mismatchTooling for a team we didn't have
A monorepo earns its keep when coordination across many teams is the bottleneck. For two people sharing everything already, it just added a build graph, a remote cache, and a class of problems we'd never have had otherwise.
Adopt the constraint, not the cargo. Most “best practices” are answers to problems you don't have yet.
We split into a handful of small repos with boring CI. Build times dropped, the mental model got simpler, and we stopped maintaining tooling whose only justification was that bigger companies used it.