Scaling a TypeScript monolith to 50 engineers
Module boundaries, build pipelines, and the lessons learned splitting one giant repo into something humans can actually navigate.
The thesis
A monorepo only stops scaling when the humans inside it stop scaling. Here is how we kept ours boring.
1. Boundaries, not folders
Folders are vibes. Boundaries are enforced. We adopted a strict layer dependency rule via ESLint and a custom Nx generator.
2. Build time is a feature
We treated incremental build performance like a product metric — tracked weekly, regressions blocked PRs. p90 CI dropped from 12 min to 3 min.
3. Module ownership
CODEOWNERS at the package level, not file level. Reviewers were chosen automatically by ownership graph instead of by guesswork.
Result
Forty-eight engineers, one repo, ~110 packages, and a green main branch for 11 weeks straight.
Related posts
The dev environment I actually use in 2026
Five years of YAML archaeology condensed into a setup that finally feels boring — in a good way.
AI pair programming, eighteen months in
What changed in my workflow, what didn't, and the practices that 10x'd the value of the tools I already had.
A small team's guide to running on Kubernetes
Yes you can. No you probably shouldn't — until you should. Here is the decision tree.