How to Ship SaaS Faster With a Shared Foundation
A governed base layer that every new venture inherits is why company number two costs a fraction of company number one. Here is what belongs in it and what does not.
The expensive part of a new SaaS is almost never the idea. It is rebuilding the same plumbing you already built last time. Auth, again. Billing, again. The guardrails that keep the model honest, again.
A shared foundation kills that repeat cost. The first company pays for the base layer in full. Every company after that inherits it and pays only for what makes it different.
What actually belongs in the foundation
The foundation holds the things that are the same across every product because they are not the product. For me that is a specific list:
- auth and identity, so I never reimplement login and permissions
- the data layer and its access patterns, owned and self-hosted
- billing and subscription handling
- the governance guardrails: claims discipline, human-in-the-loop at the dangerous actions, audit trails
- deploy and the path to production
The test for the list is simple. If getting it wrong would be wrong the same way in every venture, it belongs in the foundation. Governance is the clearest case. The rule that the software will not lie and will not do damage cannot live in each product separately, because then it is enforced nineteen slightly different ways. It lives once, underneath, and every venture inherits it by construction. This is what I mean by AI-native on one base, which I unpack in What AI-native actually means.
What has to stay product-specific
The foundation is a trap if you put too much in it. Anything that encodes a real decision about a particular market has to stay in the product, or you end up with a base layer that fights every new venture instead of carrying it.
So the domain model stays in the product. The workflow stays in the product. The interface, the pricing logic that reflects a specific buyer, the language of the thing, all product. The foundation should be opinionated about safety and identity and money, and silent about what the product is actually for.
Keeping the base layer from becoming the bottleneck
A shared foundation can quietly become the thing that slows everything down. If every new product needs the base layer changed before it can ship, you have not built a foundation, you have built a queue.
The fix is to treat the foundation as something products extend, not something they edit. A new venture should be able to add its own behavior on top without reaching into the shared layer. When a product genuinely needs the base layer to change, that change has to be backward-safe for everything already running on it, because nineteen things depend on it. The discipline is the same as the governance discipline: the foundation makes promises, and it does not get to quietly break them.
Why this is the whole strategy
This is not a tidiness preference. It is the reason the portfolio is possible. Capability is cheap now. The model writes most of the product-specific code. What stays expensive is the trustworthy plumbing underneath, and that only has to be paid for once.
My flagship, Agency Script, is the clearest expression of it: an operating system built so the hard, governed parts are inherited and the product-specific parts are all that is left to build. Company number two is cheaper than company number one because most of company two already existed before I started.