Build vs. Buy Is Dead

There's a third path. And it changes who wins.

My Take:

Early in the life of every company I’ve built, I deliver some version of the Blueberries & Pancakes Speech. It goes like this.

A new customer comes in. They signed the contract. Now they want things. And not just the things we sold them — adjacent things, weird things, things that definitely weren’t in the spec. My team’s instinct is to point at the contract and say, “That’s not what we agreed to.”

Wrong answer.

“If the customer asks us to bring them pancakes with blueberries on Saturday at 7:30,” I tell them, “we’re gonna do it.”

They look at me like I’ve lost it. “What do blueberries or pancakes have to do with software?”

Nothing. Doesn’t matter. The point isn’t the pancakes, the point is the posture. Get obsessed with dazzling the customer, not with policing the letter of what you promised. Early on, that’s how you earn the right to keep building.

Here’s the problem. That posture is necessary in the beginning but it just doesn’t scale. If you’re too responsive — yes to every request, every edge case, every “can you just add this one thing” — you stop being a software company and start being a consultancy. The coordination costs eat you alive and your roadmap turns into a junk drawer.

So what happens? You grow up. Product roadmaps become tree trunks, steady and thick like a good piece of oak. Occasionally there’s a spindle or a branch hanging off that trunk, depending entirely on how much extra a customer was willing to pay for a customization. (There’s always a price, if you’re a sensible businessperson.) But the overall thrust is to keep customers connected to the central trunk and to tame their baser instincts to deploy stuff that is a reaction to their unique business quirks but uninteresting to everybody else.

That tension — dazzle the customer vs. protect the roadmap — has defined enterprise software for as long as I’ve been building it.

But there’s a third path now. Not Build. Not Buy. Build-With.

Let me explain why Build vs. Buy existed in the first place, because that’s the key to understanding why it’s falling apart.

There’s an old concept in economics called transaction costs, first identified by Ronald Coase in the 1930s.

Nobel Prize winning economist Ronald Coase

The idea is simple: getting exactly what you need from someone else costs more than the price tag suggests. The back-and-forth. The specs that never quite capture the thing. The coordination. The compromises. When all that friction gets high enough, you stop trying and just do it yourself.

Build vs. Buy is the enterprise software version of Coase’s problem. Every branch on the tree, every custom feature, every customer-specific tweak, comes with a conversation, a spec, a sprint, and a maintenance burden that never ends. When the friction is that high, you’re stuck: build it yourself and bleed time and money, or buy someone else’s product and learn to live with their choices. Pick your poison.

When you sign a contract with one of my companies, you’re getting what’s on the back of the truck plus access to a compelling roadmap. Pre-existing capabilities and privileged access to what’s next. Custom jobs have always been too expensive to deliver and to maintain, so I never promised them.

That’s what’s changing. AI is eliminating the pain-in-the-ass factor. If you’ve heard people talking about a “post-Coasian economy,” this is what they mean: the friction that forced the build v buy choice in the first place is falling apart.

AI can manage variation at a scale that used to be impossible. Keeping track of what Customer A needs versus Customer B. Preventing one update from breaking a dozen custom edge cases. Keeping the whole thing from flying apart when the product is being pulled in fifteen directions at once. That’s the work that made customization too expensive to touch, and it turns out AI is good at it. Define, spec, and QA complex software in weeks, not quarters, and keep the books on all of it. That used to require a team. Now it requires a stack.

So now Build-With has legs. Customers can get their pancakes without their vendor losing the plot. Product roadmaps don’t have to be tree trunks anymore. They can get spindly, branches everywhere, each one tailored, each one actually maintained, because the cost of supporting all those variations has dropped through the floor.

Customers get the sensation of choosing their own adventure, with software shaped to fit their setup instead of the other way around. And on my side of the table, I still get to run a coherent product with a clear direction. I just have better tools to do both at once.

The deal in enterprise software has always gone like this: take our roadmap, learn to live with it, and in exchange you get reliability and scale. Build-With flips that.

The companies that figure out Build-With first are going to eat the ones still debating which poison to pick.