Build vs Buy vs AI in product development

We are now more than halfway through 2026. AI tools and LLMs are not only writing code, but are (for good and bad) taking over much of our development life cycle. Companies are scrambling to adapt their SDLCs to incorporate the use of LLMs.
Some are doing it while trying to keep a strong foundation of software best practices. Others are taking more direct steps to actively decrease their number of software developers because of the productivity gains of AI tooling.

This is not an article about the real or perceived benefits of using AI-tools in an engineering department. Some gains are real, but so are the delayed effects.

Instead, I want to revisit the old question of “build vs buy” in the age of AI. AI changed the math, but has it also changed the end result?

The Only Question That Matters

5-10 years ago, the only question that mattered was:

Is this a core differentiator for your company?

Yes -> build it.

No -> buy it.

If this was a core offering of your company, you needed to fully own its product roadmap.

Auth, payments, monitoring, incident management. Your engineers could for sure build all of it. That’s not the question. The question is whether building it makes you money, or just makes you busy. Most often it’s the second one.

And every hour spent on a non-core feature is an hour not spent on the thing that actually makes you money. That’s the real cost, not the sprint estimate.

The Bill Comes Later

Even with AI building looks cheap on day one. It isn’t.

Roughly 60-80% of a system’s lifetime cost lands after launch. Maintenance, on-call, patching, the 2am incident. Most teams get this wrong, not because they’re bad at estimates, but because “we could build this in a week” only counts the week.

Do we have the team to build this today? Sure.
But do we have the team to run it in three years?

Buying Has Bugs Too

However, buying isn’t a free pass. It’s a different set of risks, not zero risk.

The vendor gets acquired, the pricing triples at renewal (looking at you, AI-tool pricing), the feature you built your workflow around gets deprecated in a changelog nobody reads.

On the other hand. For anything touching regulated data, buying often gets you a SOC 2, HIPAA, or PCI compliance you’d otherwise have to earn the hard way through audits. That alone can sometimes settle the decision.

Buy trades “who patches it” for “who do we call.”

What AI Actually Changed

Speed… That’s the whole list.

Retool’s 2026 survey of 817 builders found 35% have already replaced a SaaS tool with a custom build, and 78% expect to build more this year. Time to prototype went from weeks to days, sometimes minutes. And 65% of people now shipping AI-assisted code don’t come from a developer background. They sit in ops, marketing, finance, etc.

So yes, a 12-year-old can ship a working app in a weekend. So can your ops team. Neither fact answers the question.

“Should we?.”

But instead focuses on can we.

And this is where it gets you: Yes, I could build my own version of PagerDuty. One week, basic functionality, done. But now I’ve built my own incident management system. Who runs it? Who patches it? Who’s on call when it goes down at 3am? Some of that can be handled by agent loops now, sure. But agent loops are not “cost free”, and for sure not “error free”.

What AI Didn’t Change

The SaaS pricing doesn’t go away just because the code shipped faster.

In some cases it got worse. Some vendors (perhaps even yourself) are adding an “AI tax” on enterprise renewals, or shifting to consumption pricing. This means that you can no longer even forecast the buy-side bill the way flat SaaS pricing let you. Someone has to carry the cost of the AI-token budget, and right now, most companies are forwarding it straight to the customer. Not because there’s no other option, but because the gains, whether from the AI tooling itself or from the headcount it let them cut (good or bad decision aside), haven’t hit the bottom line yet.

So yes, building got faster, but in most cases harder to price.

Many companies are landing on a hybrid approach: buy the commodity, build the differentiation on top. Buy the Stripe subscription, and build the decision engine that sits on top of it.

Some things stay as a decisive buy, AI or not: multi-tenant infrastructure like AWS or Stripe, where the operational scale isn’t replicable. Frontier model access or chasing prompt drift in-house is a losing game. Network-effect platforms like Slack or Figma, where the value is the graph of other users, not the feature set.

The one real shift is governance. With ops and marketing now shipping software outside IT’s line of sight, the question stopped being “can we build it” and became “can we govern what already got built within our company.” That’s a harder job than gatekeeping ever was.

The Result Didn’t Change

AI didn’t rewrite build vs buy. It just made the mistake cheaper to ship and more expensive to notice.

The only question that matters is still the same as it has always been: is this core, or is it context? Everything else, the speed, the 12-year-olds, the AI tax, the consumption pricing, is noise around that same decision. Answer it before the prototype ships. Not after it’s already running in production and someone’s paging you about it.