AI Broke the Buy vs. Build Decision

There’s a conversation I’ve had some version of for most of my career. “Why are we paying $100,000 a year for this? We could build it ourselves.”

For most of that time my first move was to question the estimate. How many engineers. How many months. What happens when the requirements change.

That defense is gone. When an engineer tells me today they can build a replacement in a month, they’re often right.

Which is exactly what makes it dangerous.

Are you actually replacing it?

Analytics is the classic. The data’s already there. Record some events, write a few queries, put charts on top. Why are we paying for Mixpanel?

And they’re right. They can build an analytics system. The question I’d ask before they start: are you replacing Mixpanel, or the five things you currently do with Mixpanel?

The team can recreate today’s dashboards and today’s events. Six months later someone needs cohorts. Then permissions, then identity resolution, then marketing wants a customer journey nobody had thought about when the internal system was built. Every one of those requests is reasonable. There’s no villain, just a sequence of sensible asks, and you either say no, in which case the replacement doesn’t replace anything, or you keep building. Scope creep on steroids.

When you buy a mature product you’re buying the company behind it: people whose full-time job is keeping it working, and thousands of customers who’ve already walked into edge cases you haven’t reached yet. You look at a product and say, we only use 20% of this. Maybe. Or maybe you only know about 20% of what you’re going to need.

The build isn’t the expensive part

There’s an old enterprise term that deserves a comeback. Total cost of ownership.

Say you’re paying $100,000 a year for a SaaS product. Someone says they can replace it in a month. An engineer costs $200,000 a year. Spend a fraction of one engineer’s time, kill a six-figure recurring line item. On a slide, it’s a banger.

What happens after the month? Who owns it. Who fixes it. Who decides what gets built next. Who handles the security issues and the dependency churn. What happens when the person who built it leaves. And the one nobody asks: what else was that person supposed to be doing?

AI can turn three months of development into three weeks. It can’t give you the three weeks back.

Then ask why the product costs $100,000 in the first place. Sometimes it’s margin you can delete. Sometimes the problem is just expensive: enormous data volumes, model calls, search indexes, licensed data, infrastructure that runs whether anyone logs in or not. Rebuild it and you inherit those costs without the vendor’s economies of scale. Compare the vendor’s price to your total cost of becoming the vendor. Almost nobody runs that number.

The orphan product

I’ve watched this one play out many times. Someone inside the company sees a problem and builds something. Reporting, deployment tooling, some internal workflow nobody else wanted to touch. A few weeks later they announce it, like magic. “Look what I built. Your problem’s solved.”

That’s usually where the problem starts. Nobody gave it a budget, a roadmap or an owner. The person who built it has an actual job, and eventually that job matters more. Then it breaks, or the business moves, and nobody has time for it. It’s half dead and still load-bearing.

AI makes this worse because the initial investment is close to invisible. A useful tool appears in an afternoon. Ten people use it. Then fifty. Then a critical workflow gets attached to it. AI compressed the distance between an idea and technical debt down to about a day. Wild.

Buying can do the same thing from the other direction. Buy the best email tool, the best analytics product, the best CRM, then wire them all together. You bought six products and built a seventh. The integration layer has no vendor, no support contract, and it’s the one that breaks at 2am, and then you’re screwed.

Sometimes you should build

Years ago I was consulting at Rohm and Haas, before Dow acquired them, working on their workflow and automation tools. There wasn’t a product to buy, and not for lack of looking. The process was theirs. Nobody outside that building had run into it, so nobody had built for it. That’s the cleanest argument for building there is. What you buy in a mature product is a thousand other people’s encounters with the problem, and here there weren’t any.

The process was also going to keep changing, and I didn’t want every change in how the company worked coming back to me as another software project. So instead of hard-coding the workflow I abstracted it into a state machine and put an editing interface on top. They could change it themselves as the process evolved. No call to me, no release.

It ended up a corporate standard, used all over the company on processes I never saw, precisely because the one thing it didn’t assume was the workflow. Narrow everywhere except the dimension I knew would move.

If you’re going to build, you need to understand the shape of the problem well enough to know what will change. “We can build it” is a statement of capability, and capability was never the constraint.

Where AI actually changed the answer

Experimentation.

If you don’t know what you need, build something. Spend a day. Give it to five people. Find out the feature everyone called critical doesn’t get used. Then throw it away.

That last move is the one people can’t do. We’ve treated software like a building: if we’re spending the money to put it up, it had better last. AI means software can be scaffolding. Building to learn and building to own are different decisions. AI radically changed the economics of the first. It barely touched the second.

So when someone tells me they can replace a $100,000 product with a month of work, I don’t argue with the estimate anymore. I ask who owns it when they’re done.

AI made code cheap. It didn’t make ownership free.