Build vs Buy vs AI in product development

2026-08-10 · 7 min read

We are now more than halfway through 2026. AI tools and LLMs are no longer just coding assistants; they are active participants (for good and bad) in our development life cycle. Companies are scrambling to adapt their SDLCs to incorporate the use of LLMs.
Some are integrating AI while maintaining strict software engineering best practices. Others are using AI as a lever to aggressively reduce headcount, betting that productivity gains will outweigh the risks.

This is not an article about the real or perceived benefits of the AI hype cycle. 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. The common sentiment is that AI has broken this binary. I argue that AI hasn’t broken it. It has just made the wrong choice cheaper to make and more expensive to fix.

The Only Question That Matters

Five years ago, the question was simple.

Is the new feature a core differentiator for your company?

Yes -> build it. You need full control of the product roadmap
No -> buy it.

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.

With AI, this illusion is amplified. An AI agent can scaffold a CRM in an afternoon. But who patches the security vulnerabilities in that AI-generated code? Who ensures it complies with GDPR when regulations change in 2027? Do we have the team to run it in three years, or did we just build a digital landmine?

Buying Has Bugs Too

Buying isn't a free pass. It's a different set of risks, not zero risk.

Vendor Risk: The vendor gets acquired, pricing triples at renewal, or the feature you built your workflow around gets deprecated in a changelog nobody reads.
The "AI Tax": Many vendors are shifting from flat SaaS pricing to consumption-based pricing. This makes forecasting difficult. You can no longer predict the bill the way you could with a $50/month license.
Compliance Wins: On the flip side, for anything touching regulated data (HIPAA, PCI, SOC 2), buying often provides immediate compliance certifications you’d otherwise have to earn the hard way. This alone can sometimes settle the decision.

Buy trades "who patches it" for "who do we call."

AI-as-a-Service vs. Internal AI Teams

Beyond Build and Buy, there is a third option that emerged in the 2024–2026 AI boom: Building Internal AI Teams.

Many companies rushed to hire prompt engineers, fine-tune models, and build custom RAG pipelines, believing this would create a competitive moat. By 2026, the lesson is clear: For most non-AI-native companies, building an internal AI stack is a "Context" trap.

Build an Internal AI Team: You are now in the business of managing model drift, GPU costs, and prompt security. This is hard, expensive, and rarely a differentiator.
Buy AI Capabilities: Use specialized AI SaaS tools (e.g., AI-powered legal review, AI-driven customer support) that are already solving the hard problems of model selection and compliance.

I am not saying "never build." There are cases where building AI infrastructure is the right call:

You're an AI company: If your model is your product, building it in-house is non-negotiable.
You have proprietary data that can't leave your network: Healthcare, defense, and some financial institutions simply cannot send sensitive data to third-party APIs.
Your scale makes per-API pricing unworkable: At massive scale, consumption-based pricing from vendors can exceed the cost of an in-house team — but only if you've already proven product-market fit.

If none of these apply to you, you're probably overthinking it. Buy the AI capability. Don't build the AI infrastructure.

What AI Actually Changed

Speed... That's the whole list.

Time to prototype went from weeks to days, sometimes minutes. And roughly 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 marketing intern can now ship a working CRM in a weekend. That's powerful. It's also terrifying, and it doesn't answer the question: should they?

But instead of focusing on should we, teams are focusing on can we. And that's where it gets you.

Yes, you could build your own version of PagerDuty. One week, basic functionality, done. But now you've built your own incident management system. Who runs it? Who patches it? Who's on call when it goes down at 3 AM? Some of that can be handled by agent loops now, sure. But agents are also prone to hallucination, rate limits, and cascading failures.

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

The one real change AI brought isnøt technical. It's governance.

With ops, marketing, and finance 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?"

That's a harder job than gatekeeping ever was. You can't review every AI-generated PR. You can't manually audit every line of code shipped by a non-developer. What you can do is establish guardrails: security scanning, cost monitoring, compliance checks, and clear ownership.

Governance isn't about saying no. It's about making sure that when things break - and they will — you know who owns the fix.

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 non-developers shipping code, the AI tax, the consumption pricing, is all noise around that same decision. Answer it before the prototype ships.

The teams that win won't be the ones who build the most. They'll be the ones who build the right things, and buy everything else before the AI tax compounds.

Start with the question. Answer it. Then ship.