Mistakes to Avoid When Building a Shared Foundation

Most shared foundations fail for the same handful of reasons, and none of them are technical. They fail because someone abstracted too early, nobody owned the result, product logic leaked into the core, or changes shipped without versioning and broke everything downstream. I have made every one of these mistakes across a portfolio of companies. Here is what each looks like, and how to avoid paying for it twice.

Mistake one: abstracting before you have two real cases

The most expensive mistake is building the shared version of something the first time you see it. You write an auth module for product one, decide it is obviously reusable, and hoist it into the foundation. Then product two shows up with slightly different needs, and now your abstraction is wrong for both. You either bloat it with flags or fork it, and either way you lost.

The fix is a hard rule: nothing enters the foundation until a second venture actually needs it. One case is a feature of that product. Two cases is the first evidence of a real pattern. Wait for the second. Premature abstraction feels like leverage and behaves like debt, which is the opposite of the compounding you were after when you read about infrastructure that compounds.

Mistake two: nobody owns the shared core

Shared code that everyone can change and nobody is responsible for rots fast. Each product adds the one thing it needs, no one removes anything, and within a year the foundation is a junk drawer that every team works around instead of through. A foundation people route around is worse than no foundation, because you paid to build it and still got fragmentation.

The fix is an owner with the authority to say no. Someone decides what goes in, what stays out, and what breaks on purpose. For me that is me, since I run the portfolio solo, but the principle scales: name the owner, give them veto power, and make additions earn their place. This is the same discipline that makes treating the platform as a real product work at all.

Mistake three: letting product logic leak into the foundation

The foundation is plumbing. The moment product-specific logic leaks into it, you have coupled unrelated companies together, and a change one product needs now risks breaking four others. I have seen a foundation grow a special case for one venture's pricing model, and six months later nobody could touch billing without a full regression sweep across the portfolio.

The fix is a clean boundary. The foundation handles what is genuinely identical across products: auth, billing mechanics, deploy, logging, the base data layer. The thing a customer actually pays for stays per venture. If a foundation change requires you to reason about a specific product's domain, it does not belong in the foundation. Keep the shared core boring and generic, and keep the interesting, differentiated work out of it.

Mistake four: shipping changes without versioning

A shared foundation has consumers, and consumers break when you change things under them. Ship a change to the shared billing module with no version discipline and you can take down every venture at once. This is the mistake that turns leverage into a liability, because the same reach that lets one improvement help everybody lets one regression hurt everybody.

The fix is to treat your own foundation like a vendor you depend on. Backward compatible by default. Deprecations announced before they land. Migrations that ship as scripts, not as a note telling each team to update their code and hope. I run foundation changes through the same spec-driven development loop I use for product work, and I ship them with Bootspring so a shared-core change arrives as tested code with a real diff, not a wish.

Mistake five: building it when you should not

The last mistake is building a shared foundation at all when your situation does not call for one. If you ship a new product every few years, the coordination overhead of a shared core costs more than it saves, and you would be better off copying what you need per project. A foundation pays off when you ship often enough that the reuse discount outruns the maintenance tax. That is why I build twenty companies on one, and why a single-product team probably should not.

Avoid these five and a shared foundation compounds. Hit them and it becomes the dead weight everybody quietly works around.