Compounding Foundations

In the early 1970s, the people building Unix made a decision that looks tiny written down. Programs should do one thing, read text from their input, and write text to their output, so you could chain them together with a pipe. That's it. No grand roadmap. A convention about how small tools talk to each other.

Fifty years later, that one convention is still paying out. Every shell pipeline, every grep | sort | uniq, every build script anyone has ever written stands on it. The decision compounded. The people who made it could not have enumerated the things it would make possible, because most of those things hadn't been invented yet.

That's the strange property of foundational decisions. Their value isn't in what they do. It's in what they let other things do, over and over, for a long time.

Foundations compound. Features depreciate.

Most of what a product ships is surface. A feature lands, gets used, and settles into a steady, finite level of value. Useful, but it doesn't get more useful on its own. Some of it decays as fashion and the rest of the product move on.

A foundational decision behaves differently. It starts slow and bends upward, because everything built on top of it inherits its benefit. A good data model makes every feature that touches data a little easier to build. A clean set of primitives makes the next ten things faster, and the ten after that.

This is the same shape as compound interest, and it has the same counterintuitive consequence: the early difference between a compounding decision and a flat one is almost invisible, and the late difference is enormous. Two products can look identical in year one. By year four, one of them ships features in days and the other is fighting its own foundation, and the gap traces back to a handful of choices made when nobody was looking.

Why the good ones get starved

Here's the problem. On the day you make it, a foundational decision looks exactly like a cosmetic one. Both are just work. The compounding hasn't started yet, so there's nothing to point at.

And the payoff, when it comes, shows up later and accrues to someone else. The person who designs the clean primitive rarely gets credit for the velocity it creates two years on. The person who bolts on the flashy feature gets the demo and the launch post this quarter. Roadmaps are built by people under quarterly pressure, so the visible-but-flat work crowds out the invisible-but-compounding work almost every time.

The decisions that matter most live in the top-left of that picture: invisible today, compounding for years. It is the single hardest quadrant to fund, because nothing in it demos. You cannot show a data model at an all-hands. You cannot screenshot a good abstraction.

The best framework I know for fighting this is Dan McKinley's "Choose Boring Technology," and its core idea is a budget. You get a small number of innovation tokens. Spend them on the few places where novelty actually compounds, and be aggressively boring everywhere else. The discipline isn't "never do anything new." It's refusing to spend your scarce novelty on things that won't pay it back.

Non-obvious decisions are the moat

There's a strategic reason to care about this beyond velocity, and it's sharper than it used to be.

Software itself stopped being a moat a while ago. Anyone can build the feature. What's left as durable advantage is the pile of non-obvious decisions a product has accumulated: the data model that took three painful migrations to get right, the integrations nobody wants to rebuild, the customer context that took years to gather. These are hard to copy precisely because they weren't obvious and weren't free. A competitor can clone your interface in a weekend. They cannot clone five years of compounding decisions.

Conway's Law has been making a quieter version of this point since 1968: a system's structure ends up mirroring the organization that built it. Which means your early structural choices get baked in deep, and a competitor with a different history literally cannot arrive at the same place by copying your surface. The foundation is the part that doesn't travel.

This connects to something I wrote about context. The most defensible thing a product has is usually the context it has accumulated that no one else has. That accumulation is a compounding foundation. It just happens to be made of data and relationships instead of code.

AI raises the stakes on this

You'd think cheap, fast building would make foundations matter less. The opposite is true.

When AI makes surface features nearly free to produce, the features stop being a differentiator, because your competitor can generate them just as fast. The only thing that still separates products is the stuff that doesn't come out of a model: the foundational decisions, the proprietary data, the accumulated context. Cheap features raise the relative value of everything that compounds.

There's a trap inside this, though, and it's worth naming because it's easy to fall into right now. Not everything that feels foundational is. A lot of what teams are building today is scaffolding: elaborate workarounds for the current model's limitations. That work feels deep and important, and it depreciates fast, because the next model closes the gap and the workaround becomes dead weight. The test for whether something is a foundation or just scaffolding is simple. Ask whether it gets more valuable as the models improve, or less. A clean data model gets more valuable. A clever prompt-chain that compensates for a weak model gets less. Invest in the first kind.

The quiet discipline

So the discipline is this. Spend disproportionate care on the few decisions that compound, and accept that doing so means under-investing in the visible work that everyone can see and applaud. It means choosing the boring, durable option most of the time and saving your novelty for the places it pays back. It means being willing to do work this quarter whose payoff arrives in someone else's quarter.

I've started running a personal version of this test on my own tools and systems. Before I build something, I ask whether it will get more useful the more I use it, or whether I'll be rebuilding it in six months. The compounding ones are almost never the exciting ones. They're the small, well-placed decisions that quietly hold everything else up.

Foundations don't demo. They don't trend. Nobody writes the launch post about a good abstraction. But they're the entire difference between a product that gets stronger every year and one that has to be rebuilt every year, and over a long enough horizon, that difference is the whole game.