Monorepos promise simplicity but deliver complexity if you're not careful. Here's what bit us and how we fixed it.
We migrated to a monorepo 18 months ago. It was the right call. It was also much harder than we expected. Here's the unfiltered version.
Why we did it
We had seven repos. Shared code lived in an npm package that was perpetually two weeks behind. Every cross-repo refactor was a multi-PR nightmare. The monorepo promised to fix all of this. It delivered — eventually.
What hit us first: CI times
Our build time went from 8 minutes to 34 minutes overnight. A monorepo without a smart build system is just a slow repo. We spent month one getting Turborepo set up and teaching the team how caching worked.
What hit us second: ownership
In separate repos, ownership was obvious. In the monorepo, engineers started PRing into packages they didn't own without realising it. We added CODEOWNERS files and a lint rule that flags changes to packages outside your team's ownership. Problem solved, but it took two months to figure out.
What we'd do differently
Set up Turborepo before migrating, not after. Write the CODEOWNERS file on day one. Do a "monorepo kickoff" session to walk every engineer through the new mental model. We did none of these things and paid for it.
The verdict
Worth it. Cross-package refactors that used to take a week now take a day. Shared components are always up to date. New engineers understand the full system faster. We wouldn't go back.