Monorepo vs multi-repo for startups: what we've learned shipping both

This gets debated with more certainty than the evidence supports. We've shipped both: a five-portal education platform in a single monorepo, and a four-app PG accommodation platform as four fully independent repositories sharing only an API contract. Both work. Both have a specific, predictable failure mode if you pick the wrong one for your situation.

What a monorepo actually buys you

• Shared components and utilities without publishing and versioning an internal package
• One CI pipeline, one set of dependency versions, one place to run a change across every app at once
• Cross-app refactors (renaming a shared type, updating a shared API client) happen atomically in one commit

Where it starts to hurt

• Build and CI times grow with the whole repo's size, not just the app you're touching, unless you invest in proper caching and affected-only builds early
• Independent deployment cadence gets harder: a broken change anywhere can block CI for apps that didn't touch it
• Team boundaries get blurry: when everything is one repo, it's easy to accidentally couple two apps that should stay independent

What multi-repo actually buys you

• Genuine independence: each app deploys on its own schedule, with its own CI, and a broken build in one never blocks another
• Forces a real API contract between apps, because there's no shortcut to reach across and import something directly
• Easier to hand off or spin out a single app to a different team without untangling it from a shared repo

Where it starts to hurt

• Shared logic either gets duplicated across repos, or lives in a published package that now needs its own versioning and release discipline
• A change to the shared API contract requires coordinating changes across multiple repos and multiple deploy timelines
• Onboarding a new engineer means understanding several repos and how they actually connect, not one

The actual heuristic

If your apps are genuinely different products with different release cadences and possibly different teams, separate mobile apps, a separate admin console, a separate public site, multi-repo with a well-specified API contract tends to age better. If your apps are really facets of one product that need to move in lockstep, several role-based portals of the same platform, for instance, a monorepo's atomic cross-app changes are worth the CI investment. The mistake is picking based on team preference at day one and never revisiting it as the product's actual shape becomes clear.