Infrastructure That Compounds Instead of Decays
Most software stacks decay as they grow. The portfolio bet is the opposite: build infrastructure so every new venture inherits leverage instead of liability.
Most software gets harder to change the longer it lives. Every feature adds a little maintenance drag. Every integration adds a place that can break. The codebase that was a pleasure to work in at month three is a swamp by month thirty. That is the default path, and it is decay.
I run the portfolio on the opposite bet. Each piece of shared infrastructure is supposed to make the next thing faster to build, not slower. The difference is not effort or talent. It is whether what you accumulate is a liability or leverage.
Liabilities accumulate quietly
A decaying stack is rarely killed by one bad decision. It dies from a thousand small ones that each seemed fine. A one-off auth flow here. A custom deploy script for one app. A data model bent slightly to fit a deadline. None of these is a crime. Together they are a tax that every future change has to pay.
The tell is that the cost of the next feature keeps going up. When adding a capability to your fifth product is harder than it was on your second, you are not building infrastructure. You are accumulating debt with extra steps. The work feels like progress because code is being written, but the leverage is going the wrong way.
What makes infrastructure compound
Compounding infrastructure has a specific shape. The first time you solve a problem, you solve it once, in one place, in a way the next venture can inherit without modification. Deploy, secrets, auth, the AI-native patterns for agents and content, the guardrails that keep anything from shipping that lies or breaks. Build each of those as a foundation, not a snowflake, and the second use is nearly free.
Three design choices decide which way it goes. One: shared by default, forked only when forced. A fork is a future liability you are choosing to carry. Two: governed at the foundation, not per app. If every product re-implements its own safety, you have twenty chances to get it wrong instead of one to get it right. Three: own the layer you depend on, so an upstream change cannot silently rot the whole base. This is why I run the stack myself rather than rent it.
The test is the marginal venture
There is one honest measure of whether infrastructure compounds. Look at the cost of the next thing, not the last one. If the twentieth venture is cheaper and safer to start than the second one was, the foundation is doing its job. If it is more expensive, you have been accumulating liabilities and calling them assets.
This is the explicit goal of how I build the development layer with Bootspring. Standing up a new credible product should draw down a foundation that already exists, not start a fresh pile of debt. That is the whole point of having a foundation at all.
The boring part is the leverage
None of this is exciting. Compounding infrastructure looks like saying no to one-off conveniences, paying the cost of generality up front, and resisting the urge to fork. It is slower at the start and much faster forever after.
Decay is the natural state of software. Compounding is a choice you have to make on purpose, again and again, in the small decisions nobody sees. The payoff is that the foundation gets stronger as you build on it instead of weaker. You can see what it carries on the work page.