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 defence 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?

Software teams like building things. Give a good engineer an expensive piece of software and there’s a reasonable chance they look at it and think, I could build that.

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.

Here’s the question I’d ask before they start: are you replacing Mixpanel, or are you replacing the five things you currently do with Mixpanel?

Not the same thing.

The team can recreate today’s dashboards, today’s events, today’s questions. Six months later someone needs cohorts. Someone needs different segmentation. 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. That’s the part people miss. There’s no villain in the story, just a sequence of sensible asks.

Now you have two choices. Say no, in which case the replacement doesn’t replace the original capability. Or keep building.

That’s how a cheap replacement becomes an expensive product.

The mistake was believing version one was the whole problem.

You’re not buying code

When you buy a mature product you’re not buying its code. You’re buying the company behind it.

You’re buying people whose full-time job is keeping that product working. Product management. Support. Security. Infrastructure. QA. A roadmap.

More than that, you’re buying their accumulated encounters with the problem. Thousands of customers have already walked into edge cases you haven’t reached yet.

You see the same thing when a team decides to build its own framework. The existing ones are too complicated, too abstract, they solve problems we don’t have, our requirements are different. So the team builds something cleaner.

Then they start adding things. And adding things. And adding things.

Eventually most of the annoying stuff they deliberately left out shows up in their own framework, one commit at a time. There was a reason it was there. They just hadn’t hit the problem yet.

Commercial software is the same. 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.

We used to talk about TCO when companies made major technology purchases. You didn’t look at the purchase price alone. You looked at implementation, infrastructure, training, support, maintenance, upgrades, everything it took to keep the thing alive.

That thinking needs to come back, pointed at the software we now build with AI.

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. The math looks obvious.

That’s not the math. The cost is never where you’re looking.

What happens after the month? Who owns it. Who fixes it. Who decides what gets built next. Who trains people to use it. Who maintains the integrations. 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?

Building software consumes opportunity. If your product engineers are maintaining internal analytics or reporting or deployment tooling, they’re not working on the thing your customers actually pay you to be good at.

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

Why does it cost $100,000?

The other question I’d ask before rebuilding an expensive product: why is it expensive?

We look at a software company’s price and assume most of it is margin we can delete by doing the work ourselves. Sometimes it is.

Sometimes the problem is just expensive. Enormous data volumes. Expensive model calls. Search indexes to maintain, huge stores to keep warm, third-party data to license, infrastructure that runs whether anyone logs in or not.

Rebuild the product and those costs don’t disappear. You inherit them. You inherit them without the economies of scale the vendor spent years building.

So don’t compare the vendor’s price to the cost of writing the code. Compare the vendor’s price to your total cost of becoming the vendor.

That’s the real build-versus-buy calculation. Almost nobody runs it.

The orphan product

Another pattern, and I’ve watched this one play out many times.

Someone inside the company sees a problem and builds something. Reporting. Analytics. Deployment tooling. A marketing tool. Some internal workflow nobody else wanted to touch.

A few weeks later they announce it. “Look what I built. Your problem’s solved.”

That’s usually where the problem starts.

Nobody decided to create a product. 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 than the thing they handed everyone for free.

Then somebody needs a change. Or it breaks. Or the business moves.

The tool still exists. Nobody has time for it.

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. A critical workflow gets attached to it. The prototype nobody decided to own is now infrastructure.

AI compressed the distance between an idea and technical debt down to about a day.

Buying can build software too

None of this makes buying automatically right. You can create the same problem from the other direction.

Buy the best tool for email. The best analytics product. The best CRM, the best reporting platform, the best automation platform, the best customer data product. Then connect them all together.

You bought six products and built a seventh. The seventh is the integration layer, and you own that one. It has no vendor, no support contract, and it’s the one that breaks at 2am.

This is why I’m often drawn to broader platforms when a company is entering a category it doesn’t understand well. A product that does 80% of ten things can beat a product that does 100% of one, because it teaches you which of the ten actually matter.

Later you might find that one part of the process matters so much that a specialist product is worth the extra complexity. Good. Now you’re paying that complexity tax on evidence you actually have.

Don’t solve tomorrow’s licensing problem today

I’ve also seen companies build because of a licensing problem they don’t have yet.

Someone joins from another company and says: we can’t use that, at my last place it eventually cost us a million a year.

Useful information. Now do the analysis.

How does this vendor price? Per seat, per transaction, usage, flat? What would we pay at our current size? What would we have to become before that’s a million-dollar problem? Are we going to get there? And if we do, can we make a different decision then?

People carry lessons from previous companies without carrying the circumstances that produced them. So today’s engineering capacity gets spent on tomorrow’s hypothetical invoice. What’s left is a half-built internal product that costs almost nothing to run, doesn’t quite do what anyone needs, and never gets enough attention to become good.

Experience tells you what to investigate. The investigation still has to happen.

Sometimes you should build

I’ve built internal software when I thought it was the right answer.

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, and it’s the earlier one running backwards. What you buy in a mature product is a thousand other people’s encounters with the problem. When nobody else has had the problem, there’s nothing accumulated and nothing to buy.

The interesting part is that the process was 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 the workflow 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.

It was a narrow piece of software, narrow everywhere except the dimension I knew would move.

A narrow build goes wrong when it mistakes today’s requirements for the shape of the problem.

If you’re going to build, you need to understand that shape well enough to know what will change, what has to be configurable, what complexity is inherent in the problem, and what you’re deliberately choosing never to support.

My own version of this is extreme, and I’ll own it. I’m too lazy to build my own tools. I find the bare minimum that works and augment it with software somebody else maintains. No roadmap, no owner, no TCO worth the name, because when it breaks the only person it costs is me.

That’s not the recommendation I’d give a $30M company. Same decision, different blast radius. The moment other people depend on the thing, you’ve built a product whether you meant to or not.

There are real exceptions. Software that’s part of what the customer is buying. A customer-facing dashboard answering three specific questions doesn’t need a general-purpose BI platform behind it. A genuinely proprietary workflow may not fit anything on the market.

“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. Watch what happens. Find out the feature everyone called critical doesn’t get used. Discover the workflow nobody mentioned. Learn enough about the problem to make a better decision.

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. Build it to learn something, use it, take it down.

Building to learn and building to own are different decisions. AI radically changed the economics of the first. It barely touched the second.

The question changed

So when someone tells me they can replace a $100,000 product with a month of work, I don’t tell them they’re wrong. I ask.

Are we replacing the product, or replacing what we happen to use today? Why does the existing product cost what it does? Which of those costs disappear when we build, and which do we inherit? Is there a cheaper product that gets us 80% of what we need? What does rollout and training look like? Who owns the replacement? Who decides when it gets worked on? What’s likely to change? And what else could those people be doing?

Twenty years ago the biggest question in buy versus build was whether we could afford to build it. AI is making that question boring. Increasingly, we can.

The harder question is whether we want to become the company responsible for it when we’re done.

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