Your Internal Platform Is a Product, Treat It Like One
The shared foundation under a portfolio is an internal platform, and it earns its keep only when you treat it as a product with real users and a roadmap.
The shared foundation under my ventures is an internal platform, and I treat it like a product. That is the whole trick. Most teams build reusable code as a side effect, a folder of helpers nobody owns. That folder rots. An internal platform with an owner, a roadmap, and real users compounds instead. The users happen to be my own companies, but they are still users, and they still churn to copy-paste if the platform gets in their way.
What makes an internal platform a product
A product has users who choose it. My internal platform competes with the easiest alternative any builder has: fork the last project and rip out what you do not need. If my shared auth module is slower to adopt than a copy-paste, I lose, and the codebase fragments into twenty slightly different versions of the same thing.
So the platform has to win on merit every time. Clear docs. One command to wire it in. Sensible defaults that fit the next venture without a meeting. When I start a new company, the platform should feel like the obvious path, not a tax. That is the bar a product clears and a helper folder never does.
This is the same logic behind why each next venture is cheaper to ship. The savings are real only if the shared parts actually get reused, and they only get reused if they are good.
Give it an owner and a roadmap
Unowned infrastructure dies. Someone has to decide what goes in, what stays out, and what breaks on purpose. For me that someone is me, because I run the portfolio solo, but the discipline holds at any size: name an owner and give them the authority to say no.
The roadmap is short and boring by design. Billing needs usage metering. Auth needs SSO for the enterprise deals. Deploy needs faster rollbacks. Each item serves multiple ventures at once, which is the point. I do not add anything to the platform to serve exactly one product. If only one company needs it, it lives in that company until a second one asks. Two customers make a feature; one makes a liability.
I lean on tooling that keeps this loop tight. Bootspring is how I turn a spec into a shippable increment, so platform changes land as real code with tests rather than a wiki page describing intent. The foundation and the build loop are the same investment viewed from two angles.
The version and support tax you actually pay
A product has versions, and versions mean support. When I change the shared billing module, five companies feel it. That is leverage when the change is an improvement and a disaster when it is a regression. So the platform carries the boring discipline any real product carries: backward compatibility by default, deprecations announced before they land, and migrations that are scripted, not hoped for.
Here is the honest cost. You spend more on any single change than a one-off codebase would, because you are changing something five things depend on. You buy that cost back on every new venture that inherits the work for free. If you are not shipping new ventures often, the math flips and a shared platform is overhead you cannot justify. I ship often, so it pays. Be honest about which side of that line you are on before you build one.
Where the governance lives
The reason to centralize is not only speed. It is that the rules live in one place. Audit logging, permission checks, data retention, the claims a product is allowed to make: I want those baked into one governed foundation under every company, not reimplemented per venture by whoever happened to build it. Reimplemented governance is inconsistent governance, and inconsistent governance is the same as none when an enterprise buyer or a regulator comes asking.
Treating the platform as a product is what makes that possible. A product has a single source of truth for how things work. A pile of helpers has twenty. When I add an audit requirement, I add it once and every venture inherits it on the next deploy. That is the compounding I am actually after, and it only shows up when the foundation is owned, versioned, and good enough that nobody wants to route around it.
Build the platform like you would sell it. Then it is worth having.