Technical leadership

Build vs buy for AI: a decision framework for leadership teams

Leadership teams keep asking the same question about AI: build it ourselves or buy it? The answer is almost never all of one. Here is how I break the decision down.

EssaySumanta Mukhopadhyay7 min read4 sources
#leadership#strategy#ai#fractional-cto
ESSAY · TECHNICAL LEADERSHIP19 Oct 2026 · 20:30 GST

"Should we build this ourselves or buy it?" is one of the most common AI questions founders, CEOs and boards ask. It is usually framed as a single decision for the whole company. In practice it is a dozen smaller decisions, and getting the split right matters more than the headline choice.

What the evidence suggests

The research is sobering. A widely reported 2025 study from MIT's NANDA initiative found that most generative AI pilots delivered little measurable impact on profit and loss. It also reported that solutions bought from specialised vendors or built with partners succeeded noticeably more often than purely internal builds12. Press coverage varies on the study's exact methodology, so I treat the numbers as directional rather than precise.

The direction matches what earlier enterprise surveys described: organisations mixing building and buying, and moving quickly between model providers3. The lesson is not "always buy". It is that building is expensive to get right, so build only where it pays.

The layers of an AI capability

LayerDefaultWhy
Foundation modelsBuy or use open weightsTraining your own is rarely justified outside a handful of companies
Commodity features (transcription, generic chat, coding assistants)BuyVendors improve faster than you can, and switching costs are low
Data, semantics and retrievalOwnYour data and its meaning are the differentiator, and lock-in here is expensive
Workflow integrationBuild or partnerValue comes from fitting AI into how your people actually work
Evaluation and governanceOwnYou can't outsource knowing whether it works, or proving it is safe

Buy the parts that are the same for everyone. Own the parts that make your answer different from your competitor's, and the parts that let you change vendors without starting again.

Six questions that decide each case

  1. Is this a differentiator? If customers would choose you because of it, lean towards building or partnering. If it is table stakes, buy.
  2. Is the value in our data? If the capability is only good because of proprietary data or domain knowledge, you need to own that layer, even if you buy the rest. This is where an ontology and semantic layer earn their keep.
  3. How fast is the market moving? In fast-moving categories, today's build becomes tomorrow's commodity. Prefer buying with an exit plan.
  4. Can we measure it? If you can't evaluate quality, you can't compare vendors or justify a build. Start with an evaluation set.
  5. What are the data constraints? Regulated or sensitive data may rule out some vendors or require private deployments, as in where to run AI in the UAE.
  6. Do we have the team? Building means owning it for years: on-call, upgrades, evaluation, security. Be honest about capacity.

Keep the option to switch

Whatever you decide, design so you can change your mind. In practice that means a gateway in front of every model, prompts and evaluation sets under your control, data in formats you own, and contracts that let you export. Frameworks such as NIST's AI Risk Management Framework are a useful checklist for the governance side of that ownership4.

I record each of these choices as an architecture decision record, with the conditions that would make us revisit it. AI vendor decisions get revisited more often than most.

Signs you chose wrong

  • A bought tool that nobody uses because it doesn't fit the workflow.
  • An internal build that a vendor now offers better, still being maintained out of pride.
  • No way to tell whether the AI is getting better or worse.
  • Switching providers would mean rebuilding prompts, integrations and data pipelines from scratch.

Each is fixable, and spotting them early is a large part of the value of an independent technical review.

How I can help

As a fractional CTO I help leadership teams make and record these decisions, then build the layers worth owning. Or analyse your challenge and bring the result to a call.

References
  1. 1
  2. 2
  3. 3
  4. 4
FAQ

Common questions

Is it better to build or buy AI?

For most organisations it is a mix. Buy commodity capabilities where vendors are strong, and build where your proprietary data, workflow or domain knowledge is the differentiator. Own the data, evaluation and governance layers either way.

Why do so many AI pilots fail?

Widely reported research from MIT's NANDA initiative in 2025 found most generative AI pilots delivered little measurable financial impact, and that purchased or partner-built solutions succeeded more often than internal builds. Common causes include unclear business outcomes, poor data and lack of integration into real workflows.

What should we always own?

Your data and its semantics, your evaluation sets, and your governance controls such as access, logging and model routing. These keep you able to switch vendors and prove quality.

Keep reading

Related

Open to advisory, fractional CTO & select builds

Let's talk about what you're building.

The fastest route is a free 30-minute call. Prefer to write? Send a message and I'll reply personally within two business days.

Start a conversation

How would you like to reach me?

Book a 30-min callFastest. Pick any open slot on my calendar.→ Write in GmailOpens a pre-filled draft in your browser.→ Use my email appOutlook, Apple Mail or your default client.→

I reply personally within two business days. US & UAE time zones.