What Belongs in a Shared Foundation and What Doesn't

What belongs in a shared foundation is the stuff that is identical across products, carries risk you want handled once, and does not make any product distinctive. What stays out is the product itself. Get this boundary right and the foundation accelerates every new venture. Get it wrong and you either build a rigid framework nobody can ship on or a junk drawer everyone works around. Here is the checklist I run before anything goes into the shared core.

In: the plumbing every product needs

Auth, billing mechanics, deploy, logging, error handling, and the base data layer belong in the foundation. Every product needs all of them, none of them differentiates the product, and each carries real risk if done wrong. Centralize them and every venture inherits working, audited versions on day one.

This is the boring, high-value core. It is where the compounding actually comes from, because it is the largest chunk of work that is genuinely the same across products. Put it in the foundation and you get the reuse discount behind each next venture being cheaper to ship without forcing any product into a shape that fights it.

In: the governance rules, always

Audit logging, permission enforcement, data retention, and the claims a product is allowed to make belong in the foundation without exception. These are the rules you cannot afford to have implemented inconsistently, because inconsistent enforcement fails the moment a buyer or regulator inspects it. One implementation, inherited everywhere, is the only version that holds up.

This is why the foundation is not just an efficiency play. It is how you keep one governed foundation under every company instead of twenty products each enforcing whatever their builder remembered. Governance is the clearest case of something that must be shared: the whole value is uniformity, and uniformity requires a single source.

Out: the product itself

The thing a customer actually pays for stays out of the foundation. Domain logic, the specific data model, the workflows and UI that make a product feel like itself: keep all of it per venture. This is where products should be free to be completely different, because being different is the entire point of a different product.

The failure mode is tasting the reuse win on plumbing and trying to abstract the product too. You end up with a configurable mega-framework that can supposedly be any product and is none of them well. If a foundation change requires reasoning about a specific product's domain, that logic is in the wrong place. Keep the differentiated work out, always.

Out: anything with only one consumer

Even genuine plumbing does not belong in the foundation until a second product needs it. One product needing something is a feature of that product. A second product asking is the first evidence of a shared pattern. Move too early and you build the wrong abstraction, the kind everyone later routes around, which I covered in the mistakes that turn a foundation into dead weight.

So the checklist has a timing rule, not just a category rule. Right category plus at least two real consumers plus stable enough that it does not need per-product tweaks. Miss any of the three and it stays out for now.

The test to apply

When I am unsure, I ask three questions. Is this identical across products, or only similar? Does being different here buy any product anything? Do at least two products need it, stably? Three yeses and it goes in the foundation. Any no and it stays per product until the answer changes.

That test keeps the core boring and generic, which is exactly what you want, because a boring foundation is a stable one, and a stable foundation is one products can build on fast without waiting on it. I keep changes to the core safe with the same spec-driven development loop I use everywhere, run through Bootspring so shared-core changes ship as tested increments, and I keep the per-product code honest on quality with ReformCode.

Centralize the plumbing and the governance, keep the product and the one-off cases out, and apply the three-question test at the boundary. That is a foundation that compounds instead of one that fights you.