Don't Build It Yourself. Especially Now.

Recently, one of the lead clients in a pilot we're running floated an idea. The capability we're building to help them grow membership: why not just take it in-house? Build their own version, own it outright, skip the subscription.

I understand the instinct. I've heard some version of it for most of my career. In consulting, every client eventually wonders whether they could just hire the people and do it themselves. Sometimes the answer is yes. Usually it isn't.

What struck me this time is that the old reasons for saying no are all still true. And there's a new one that matters more than all of them combined.

Start with the economics. We're pricing this the way most software is priced: we subsidize the development up front and make it back over time. The subscription is spread out. The cost isn't. If a client wants to own the thing outright, someone has to pay for the build on day one, and that number is a lot bigger than a year of subscription fees. Owning it means paying the whole bill at once and taking on all the risk.

Then there's maintenance. This client doesn't have an IT organization capable of maintaining code like this. Most organizations their size don't. Software behaves more like a garden than a building. Dependencies change, integrations break, security issues show up, users ask for things. Untended code rots.

Both of these were true in 2005, long before AI. They're why buy-versus-build almost always came out on the side of buy for organizations whose core business isn't software.

Here's what's different now.

For decades, software ran on a predictable rhythm. You built a product, and it stayed basically the same for three to five years. Every six months or so, you added a feature or two. Customers bought a fixed capability and expected it to stay fixed.

That rhythm is over.

The underlying models get meaningfully better every few months. Each jump opens up things that weren't possible before. A product that ships a feature or two every six months falls further behind every quarter. And the features it does ship become irrelevant to most users faster than ever, because the frontier keeps moving.

So when I think about what we'll build for this client over the next month, I know it's a fraction of the value they'll get a year from now. That's simply the rate of change. If they take a snapshot of month one and freeze it in-house, they own the least valuable version of the thing they'll ever see.

The irony is that AI has made writing software dramatically cheaper. I've written about this before: code is heading toward commodity.

Capability is a different story. When the cost of producing software falls toward zero, the value moves to the things that are still hard:

Those are the scarce things now. None of them come with the source code.

This is the part that feels backwards.

You'd think cheap software makes in-house builds more realistic. Anyone can fire up an AI coding tool and produce an app over a weekend. Why pay a vendor?

Because the hard part has always been people, and the people are getting more expensive every year. Engineers who know how to build on top of fast-moving AI systems are some of the most sought-after talent in the market. Most mid-sized organizations can't hire them, and couldn't keep them if they did.

More important than the talent is the orientation. The teams winning right now are organized around one thing: relentlessly pushing the capability of their system as the underlying AI gets better. Ship, learn, ship again. Every model release is a chance to do something that wasn't possible last month.

That orientation is a culture, and it's nearly impossible to build inside an organization whose real job is something else. An association's job is to serve its members. A manufacturer's job is to make things. Asking them to also become a product company that ships on AI's clock is asking them to run two businesses. The second one will lose.

Cheap code makes building and maintaining software internally look easier than ever. In practice it's getting harder. This is exactly the kind of thing most organizations should outsource.

If you're evaluating an AI vendor right now, stop leading with the old questions. A feature checklist is a snapshot of a moving target. Whatever's on it today will be out of date by spring.

Underwrite the team instead:

What you're really buying is a rate of improvement. Price it that way.

The more useful question for this client is: what do you want this to look like in twelve months?

Ask that honestly and the answer is always a much bigger list than what exists today. Which is the point. The real decision is who is going to build everything that comes next, and how fast.

I'll close with an unresolved piece of my thesis.

Everything above assumes the scarce skill is building and shipping software, and that most organizations will keep buying it from someone who does it full time. That's true today. It may not stay true.

If AI keeps getting more capable, the work of building software could get easy enough that knowledge-based organizations absorb it entirely. An association, a law firm, an accounting practice: each could become an AI implementation shop for its own domain. In that world, the capability I'm telling them to outsource becomes the core of what they do.

So here's where I land. For now, and for most organizations, I'm right: don't build it yourself. It’s still too hard and too expensive to get good. In a few years the answer will change but not in the way you might think. More next week.

Alan