TBM 430: Incubate, Compound, Refinance, Liquidate

tl;dr:

AI does not eliminate complexity, coupling, coordination, uncertainty, or decay. But it can change the cost, speed, and feasibility of responding to them.

or:

AI does not work in the same way across different portfolio puzzles.

---

This is absolutely not a new idea. Companies have long thought about software as a portfolio of assets, investments, bets, and liabilities. What interests me here is not the metaphor itself, but what happens when we combine it with value, carrying cost, movement over time, and AI.

This is more of a Sunday-morning diagramming and thought-provocation post than a fully worked-out framework. None of the underlying ideas are especially new. I’m mostly interested in placing a few familiar concepts next to one another and seeing what becomes easier to notice.

Let’s go!

Carrying Costs and Value

Some assets create substantial value and remain relatively cheap to carry. Some create value but have become expensive to change, operate, and support. Some are still bets. Others continue consuming resources long after their economic case has weakened.

The question is not whether the code is “good” or “bad.” It is:

What value does this asset create, what does it cost us to carry, and what should we do next?

That gives us a simple 2×2.

Place each software asset according to the value it creates and what it costs to carry. Its position suggests the basic economic posture: incubate, compound, refinance, or liquidate.

Motion and Arc

Consider the arc of a startup.

It begins with low value and low carrying costs: a relatively cheap bet. Some bets prove their value and move toward Compound. As they scale and mature, carrying costs rise, pushing them toward Refinance. From there, a healthy company either restores the economics or eventually Liquidates the asset when its remaining value no longer justifies the cost of carrying it.

Other bets never prove much value at all. When the team keeps building anyway, the product moves right without moving up, turning a cheap experiment into an expensive obligation: the build trap. Liquidation is not necessarily failure. Refusing to liquidate often is.

Once you see the portfolio this way, you can also see the different moves available.

You can expand returns, reduce drag, harvest an aging asset, scale with drag, or slip into negative compounding. But the “pure” movements are mostly abstractions. Products rarely move perfectly up, down, left, or right. Growth usually brings some additional drag. Reducing carrying costs may sacrifice some value. Harvesting is often a deliberate movement down and left.

The more interesting question is not simply where an asset sits. It is:

Which direction is it moving, how quickly, and is that movement intentional?

Debt

These categories and movements make technical debt easier to see in financial terms. Debt is a financing choice: we accept higher future carrying costs in exchange for reaching value sooner.

• In Incubate, that can be dangerous because we may take on obligations before proving the asset has value.

• In Compound, it can be rational leverage if the added drag helps expand returns.

• When the interest begins to consume too much of those returns, the asset moves toward Refinance, where the task is to restructure the system and restore its economics.

• And when the asset no longer creates enough value to justify either the debt or the cost of repaying it, the right move may be Liquidate.

The same technical debt can therefore be productive leverage, an expensive constraint, or a liability, depending on the value of the asset carrying it.Portfolio Over Time

Platforms

These categories also help clarify the difference between an effective and ineffective platform strategy. A good platform may create a visible concentration of cost, but it earns that investment by helping many other assets increase value, reduce carrying costs, or do both. A bad platform becomes another high-cost asset that pushes complexity, dependencies, and coordination overhead across the portfolio. The relevant question is not how much the platform ships or how many teams use it. It is whether the platform improves the economics of the assets that depend on it.

We’ll get into more traps later, but platforms have a fun assortment of traps to contend with:

• False Economies of Scale: We centralize similar-looking work without proving that sharing it will reduce total carrying cost.

• Platform Too Early: We standardize an emerging pattern before we understand what is actually stable and reusable.

• Platform Too Late: We wait until duplication and divergence make convergence painfully expensive.

• Adoption Tax: We reduce complexity for the platform team by pushing integration, migration, and exception handling onto consumers.

• Mandate Trap: We mistake compulsory usage for evidence that the platform improves anyone’s economics.

• Dependency Bottleneck: We centralize capabilities and accidentally centralize waiting, prioritization, and failure.

An Intentional Portfolio

There are always inflows and outflows between these categories over time. Some movements are intentional portfolio choices. Some are unavoidable byproducts of growth, scale, and aging. Others happen accidentally, through oversight, avoidance, or outright negligence.

So portfolio health is not only about the mix of assets at a given moment. It is also about what is flowing where, how quickly, and whether anyone is managing the movement.

This frame also makes it easier to see familiar organizational traps as recurring patterns of movement between the categories.

The Traps

The Build Trap is what happens when Incubate fails to become Compound, but keeps accumulating carrying cost. Limits to Growth appears when Compound succeeds, then steadily gives way to Refinance. The Success Trap emerges when current winners dominate so completely that the next generation of Incubate assets disappears.

There are plenty of other patterns hiding in the diagram. Some are failures to prove value. Some are failures to preserve the economics of value. Others are failures to renew, simplify, or finally let go.

Not A Monolithic Situation

The critical question when it comes to AI is:

Which movement are we asking AI to accelerate?

AI does not enter a neutral system. It enters a portfolio with a particular mix of bets, winners, drag, and aging assets. Depending on the situation, it can help move an asset upward, leftward, or back into healthier economics. It can also accelerate exactly the wrong motion.

Depending on the answer to that question, you can better understand the risks you need to mitigate.

For example:

• In a Build Trap, AI can help teams prototype and synthesize feedback faster. It can also make it much easier to keep building without stronger evidence of value.

• In Limits to Growth, AI can help with refactoring, migrations, dependency analysis, and automation. It can also pour more throughput into the very constraint that is already slowing the system down.

• In a Success Trap, AI can make adjacent exploration much cheaper. It can also help the company optimize its current winner so aggressively that it stops looking for what comes next.

• In a Zombie Portfolio, AI may finally make old systems affordable to retire. Or it may make them cheap enough to tolerate forever.

The same capability can improve the economics of the portfolio or deepen the pattern that created the problem. So the AI question is not simply:

Will this make us faster?

It is:

Faster in which direction?

AI does not eliminate complexity, coupling, coordination, uncertainty, or decay. But it can change the cost, speed, and feasibility of responding to them.

The physics do not change. The coefficients, thresholds, and economics may.