← Back to writing
engineering1 min read

I run 20+ apps out of a single monorepo. The trick isn't speed. It's refusing to write the same thing twice.

20+ apps, one monorepo, one reuse discipline

Rob Vasquez·

I run 20+ apps out of a single monorepo. The trick isn't raw speed. It comes from refusing to write the same thing twice.

Most teams rot the same way. App A builds auth, app B copies it, they drift, and six months later a "small" auth change means editing four codebases that no longer agree.

My rule is boring and strict. Any capability that two apps could share lives in one library that owns all the logic. Each app gets a thin adapter, usually around 50 lines, that maps its own data into the shared shape and stops there. No business logic in the app. Ever.

That's how a garage-management SaaS, a medical dashboard, and an e-invoicing product share the same auth, the same UI kit, and the same billing meters while still shipping on their own schedules.

The payoff isn't in any single feature. It's that fixing a bug once fixes it everywhere, and a new app starts at 80% done.

Hiring managers ask if I can move fast. Honestly? I move fast because I built the discipline that lets me.

What's the worst copy-paste-gone-wrong you've inherited? I'll go first in the comments.

SoftwareArchitectureMonorepoTypeScriptEngineeringLeadership

Need a practical path to AI-enabled delivery?

Start with a fixed-price AI-readiness audit and leave with a concrete roadmap.

View the AI-readiness audit