Build, Buy or Partner

The idea in one minute#

For any AI capability there are four ways to get it: buy a finished product, configure one on a low-code platform, build on a managed AI platform, or run it yourself on your own infrastructure. Each step gives more control and takes more people, time and risk.

The decision is not about technology. It turns on one question: is this capability something that makes the organisation different from its competitors? If not, buy it — a vendor who sells the same thing to a thousand customers will always do it better and cheaper. If it is, build it, because that is where your own data and process knowledge pay off.

Most enterprises end up with all four at once: bought assistants for everyday work, low-code for departmental automations, custom builds for the two or three processes that define the business, and self-hosting only where a hard constraint forces it. The architect’s job is to place each use case on the right step — and to resist the engineer’s instinct to build everything.

A picture#

flowchart LR
  Q1{"Does it make us<br/>different from<br/>competitors?"}
  Q1 -->|"no"| Q2{"Does a product<br/>meet the<br/>requirements?"}
  Q2 -->|"yes"| BUY[":i-package: <b>Buy</b><br/><small>SaaS assistant or specialist product</small>"]
  Q2 -->|"nearly"| CFG[":i-wrench: <b>Configure</b><br/><small>low-code agent builder</small>"]
  Q1 -->|"yes"| Q3{"May the data use a<br/>managed platform?"}
  Q2 -->|"no"| Q3
  Q3 -->|"yes"| BLD[":i-code: <b>Build on a platform</b><br/><small>managed models, your logic</small>"]
  Q3 -->|"no"| Q4{"Volume large and steady,<br/>or data must stay inside?"}
  Q4 -->|"yes"| RUN[":nvidia: <b>Run it yourself</b><br/><small>open weights, your GPUs</small>"]
  Q4 -->|"no"| BLD
  class Q1,Q2,Q3,Q4 queue
  class BUY,CFG neutral
  class BLD compute
  class RUN warn

How it really works#

The four options#

Microsoft’s Cloud Adoption Framework describes the same ladder as four adoption models — ready-made Copilots, low-code development, managed platform development and infrastructure — with the trade stated in one line: as you move down, you gain control and give up speed.

Six questions that decide it#

What the evidence says#

The MIT Project NANDA study of 2025 reported that pilots built with an external vendor reached deployment roughly twice as often as those built purely in-house. Treat the exact ratio with care — the study was preliminary — but the direction matches what practitioners see: internal teams underestimate everything around the model. Integration, evaluation, change management and operation are the bulk of the work, and a vendor has already done them once.

The corrective is not “always buy”. It is: build only where you are prepared to own a product, with a product owner, a roadmap, an on-call rota and a budget line that does not end at launch.

The hidden costs of each#

A useful rule: for a custom build, the cost to run and maintain it for three years is commonly two to four times the cost to build it. If the business case only covers the build, it is not a business case.

Self-hosting: when the arithmetic works#

Running open-weight models on your own or rented GPUs is a real option with a narrow window. The per-token price looks tiny; the question is utilisation. A GPU costs the same whether it serves one request or a thousand, so:

cost per million tokens  =  GPU cost per hour  ÷  (tokens per second × 3600 × utilisation)  × 1,000,000

Self-hosting wins when three things are true together: volume is large, load is steady enough to keep the hardware busy, and an open model passes your evaluation. It is forced, regardless of cost, when data may not leave the organisation or the site has no reliable connection. For everything else — small, spiky or frontier-quality workloads — the hosted API is cheaper once engineers are counted. The mechanics are in Compute and Capacity.

Partnering#

“Partner” is a fourth axis rather than a fifth option: who does the work.

Whatever the arrangement, write three things into the contract: you own the prompts, the evaluation sets and the data; the partner documents every decision; and your people are in the team from day one, not at handover.

Evaluating a product you might buy#

Vendors demonstrate on their best case. Test on yours.

1. Run your evaluation set through it. The same 50–200 real cases you would use to choose a model. A vendor who will not allow this has answered the question.
2. Ask where the data goes. Which model, which region, retained how long, used for training or not, which sub-processors.
3. Ask what you can see. Logs, traces, the sources behind an answer, usage per user.
4. Ask what you can control. Prompts, guardrails, model choice, permissions, the off switch.
5. Ask how you leave. Export of data, prompts and history; notice period; price caps on renewal.
6. Ask which position on the autonomy dial it really occupies, and what enforces the limits. See Workflows and Agents.

Keep the decision reversible#

• Put a gateway between your applications and any model or vendor.
• Keep prompts and evaluation sets in your own repository.
• Expose internal systems as MCP tools once, so a bought agent and a built one can use the same integrations.
• Prefer contracts with short terms early, when you know least.
• Re-decide yearly. A capability that had to be built in 2024 can often be bought in 2026.

Code#

Three-year cost of the same capability bought per seat, built on a managed platform, and self-hosted. The inputs are illustrative; replace them with yours.

// buildbuy.go — three-year cost of buying, building and self-hosting one capability.
package main

import "fmt"

func main() {
	const years = 3.0
	users := 1_500.0
	activeShare := 0.6 // share of licensed users who actually use it
	tasksPerUserPerDay, workdays := 12.0, 220.0
	tasks := users * activeShare * tasksPerUserPerDay * workdays // per year

	// Buy: per-seat licence, light integration, an administrator.
	seat := 30.0 * 12 // dollars per user per year
	buy := years*(users*seat+0.5*160_000) + 60_000

	// Build on a managed platform: a team, then a smaller team; pay per token.
	inTok, outTok, inP, outP := 7_000.0, 500.0, 2.0, 10.0
	perTask := (inTok*inP + outTok*outP) / 1e6
	buildOnce := 4 * 0.75 * 180_000.0 // four engineers for nine months
	runTeam := 2 * 180_000.0          // two engineers, ongoing
	platformFees := 40_000.0          // search index, monitoring, storage
	build := buildOnce + years*(runTeam+platformFees+tasks*perTask)

	// Self-host: same build, plus GPUs and a platform engineer.
	gpus, gpuHour := 4.0, 3.50
	gpuYear := gpus * gpuHour * 24 * 365
	self := buildOnce*1.3 + years*(runTeam+180_000+platformFees+gpuYear)

	fmt.Printf("tasks per year: %.1f million\n\n", tasks/1e6)
	fmt.Printf("%-22s %14s %14s\n", "option", "3-year cost", "per task")
	for _, o := range []struct {
		name string
		cost float64
	}{{"buy (per seat)", buy}, {"build on platform", build}, {"self-host", self}} {
		fmt.Printf("%-22s %14.0f %14.3f\n", o.name, o.cost, o.cost/(tasks*years))
	}

	fmt.Printf("\nmodel tokens are %.0f%% of the build option's 3-year cost\n",
		100*years*tasks*perTask/build)
	fmt.Printf("people are %.0f%%\n", 100*(buildOnce+years*runTeam)/build)
}

The result that surprises people: in the build option, model tokens are a small share of the total and people are most of it. Arguments about token prices are usually arguments about the wrong line.

Remember this#

• Four options: buy, configure, build on a platform, run it yourself. More control, more cost.
• Buy what everyone needs the same way. Build what makes the organisation different.
• Running a custom build for three years costs two to four times what building it did.
• Self-hosting needs large, steady volume and an open model that passes your evaluation.
• Test a vendor on your evaluation set, and keep the decision reversible.

Try it#

1. Run buildbuy.go. Change users to 150 and then to 15,000. At what scale does building become cheaper per task than buying?
2. Place five AI capabilities at an organisation you know on the four-option ladder using the six questions. Which did you place differently from how they were actually delivered?
3. Write the six product-evaluation questions as an email to a vendor. Which answers would make you walk away?

Check yourself#

1. What single question most often decides build against buy?
2. Why do in-house builds stall more often than vendor-led ones?
3. Which three conditions must hold together for self-hosting to be cheaper?
4. Name three things that keep a build-or-buy decision reversible.

Sources#

• Microsoft Cloud Adoption Framework: AI strategy (dated 26 June 2026) — the four adoption models
• MIT Project NANDA: The GenAI Divide — State of AI in Business 2025 (press coverage of a preliminary report)