Monorepo vs Polyrepo for a Portfolio Foundation

For a portfolio with a shared foundation, the monorepo vs polyrepo question is really a question about where you pay the coordination cost. A monorepo pays it up front, in tooling and build discipline, and hands you atomic changes across every product. A polyrepo pays it later, in version drift and integration pain, and hands you clean isolation. I run a hybrid, and I will tell you exactly where I draw the line and why.

What each model actually buys you

A monorepo puts every product and the shared foundation in one repository. The win is atomic change: I can update the shared billing module and every consumer of it in a single commit, and CI proves nothing broke before it merges. There is no window where product A is on the new version and product B is on the old one. For a shared foundation, that is a big deal, because the whole value of shared code is that everyone runs the same code.

A polyrepo splits every product into its own repository, with the foundation published as versioned packages. The win is isolation. Each product has its own history, its own permissions, its own release cadence, and a blast radius that stops at its own walls. A junior on one product cannot accidentally touch another. The cost is drift: product A pins version 3 of the foundation, product B is still on version 1, and now your one governed foundation is quietly three different foundations in production.

That drift is the thing I care most about, because it undermines the entire reason to have one governed foundation under every company. If the audit rules live in the foundation but three products run three versions of it, the rules are not actually uniform.

When the monorepo wins

The monorepo wins when the foundation changes often and correctness across products matters more than isolation. That describes my situation. I am one operator changing shared plumbing regularly, and I want a change to auth or billing to hit every venture at once, provably, without a migration campaign across twenty repos.

The cost is tooling. A monorepo needs a build system that only rebuilds what changed, or your CI time explodes as the repo grows. It needs code owners so the wrong person cannot merge into the shared core. It needs discipline that a small pile of repos does not demand. If you are not willing to invest in that tooling, a monorepo becomes a slow, tangled mess, and the polyrepo would have served you better.

When the polyrepo wins

The polyrepo wins when products are genuinely independent, teams are separate, or a product might be sold or spun out. A repo you can hand to a buyer or a separate team without untangling it from everything else has real option value. If your ventures do not share much and rarely change the foundation together, the isolation is worth the drift risk, and versioned packages are a perfectly good way to ship shared code.

It also wins when security boundaries have to be hard. Some products touch data that other products should never see. Repo-level separation is a clean, auditable way to enforce that, cleaner than access rules inside one giant repo.

The hybrid I actually run

I keep the shared foundation and most ventures in a monorepo, so foundation changes are atomic and drift is impossible by construction. Products that need a hard security boundary, or that might get spun out, live in their own repos and consume the foundation as versioned packages. The rule is simple: default to the monorepo for the compounding, split out only when isolation earns its cost.

Whichever you pick, the deploy story has to be owned end to end. I run every product through the same pipeline I control, which is the whole point of owning your deploy pipeline rather than renting it. And I keep foundation changes honest with the same spec-driven development loop I use everywhere, run through Bootspring so a shared-core change ships as tested code, not a hopeful commit.

The repo layout is not the point. Keeping one real foundation instead of twenty accidental ones is the point. Pick the model that makes drift hardest for the way you actually work, and pay the coordination cost where it hurts least.