The monorepo trap, and how an engineering org of forty people walked right into it
· 1 min readA monorepo is a single source-controlled tree containing many packages. The pitch is appealing: shared tooling, atomic cross-cutting changes, and no version drift between internal libraries.
The reality, once your team passes a certain size, is more nuanced.
The problem
CI times balloon. Builds that should take ninety seconds take twenty minutes. Engineers learn to wait, and waiting kills momentum.
What I’d do differently
Start with separate repos. Move to a monorepo when the cross-cutting change overhead becomes the dominant cost, not before.