All Posts
SaaS Platform

Build vs. Buy for AI Features: The Three-Layer Test

"Build vs. buy" is the wrong question for an AI feature. Split it into three layers — model, orchestration, surface — and a five-question test tells you which one to build and which to rent.

10 min read

"Build vs. buy" is the wrong question for an AI feature. There are three layers — the model, the orchestration around it, and the product surface — and you make a different call on each. You buy the model; that argument is over. You build the surface; it is your product. The only real decision is the orchestration layer: the retrieval, prompt assembly, tool calls, memory, and budget logic that turn a model into a feature. My default there is build-thin, and Claude Sonnet 5 shipping on June 30 as a near-Opus agent at $2/$10 per million tokens is why: the cost of building that layer yourself just dropped below the cost of renting someone else's. Buy the model, own the orchestration, build the surface — and the 40%-plus of agentic AI projects Gartner expects to be canceled by 2027 are mostly teams that made the buy/build call at the wrong layer.

Why this matters now

Two things changed this summer. First, on June 30 Anthropic made Sonnet 5 its default model — close to Opus-class agentic performance at roughly a third of the price, with introductory pricing of $2 per million input tokens and $10 per million output through August 31 (Opus 4.8, for comparison, is $5/$25). When the frontier model that can plan, call tools, and check its own work costs this little, "we don't have the resources to build it" gets much weaker as an argument for buying a packaged AI agent. Building the thin orchestration layer around a bought model is now a week of work, not a quarter — and the introductory-pricing window makes the next few weeks the cheapest time to do it.

Second, the bill is coming due for the teams that bought without thinking. Gartner expects more than 40% of agentic AI projects to be canceled by the end of 2027 — not from bad models, but from escalating cost, unclear business value, and inadequate risk controls. The same analysis names "agent washing": vendors rebranding chatbots and RPA scripts as autonomous agents, with only about 130 of the thousands of vendors making the claim doing anything genuinely agentic. If you are buying an "AI agent," there is a sub-2% chance the thing behind the logo is what the label says.

Put those together and the picture is clear. It has never been cheaper to build the part that differentiates you, and it has never been riskier to buy the part you cannot see inside.

The three layers, and where the decision actually lives

Stop treating an AI feature as one buy/build decision. It is three, and they are not close calls in the same way.

The model is the foundation — the LLM that does the reasoning. This is settled: you buy it. Training or self-hosting a frontier-class model is not a decision for a SaaS company; it is a way to set money on fire. Rent it from Anthropic, OpenAI, or whoever prices best this quarter, and treat it as swappable infrastructure.

The surface is the opposite. It is the workflow your user actually touches — the interface, where the feature lives in their day, how results get reviewed and acted on. That is your product. Nobody should build it but you.

The orchestration layer sits between them, and it is the only place the build-vs-buy question is real. It is the retrieval, the prompt assembly, the tool definitions, the memory, the routing between models, and the budget and eval logic. It is where your domain knowledge gets encoded and where your switching cost lives. Buy it — as a managed agent or an end-to-end platform — and you have rented your differentiation and put a meter between yourself and your unit economics. Claude's managed-agent runtime, for instance, bills $0.08 per session-hour on top of tokens: reasonable for convenience, punishing if a session-heavy feature is the core of your product and every active user runs the meter.

So the rule of thumb is one sentence: buy the model, own the orchestration, build the surface. The code that makes "own the orchestration" cheap is a thin boundary — an interface the rest of your app talks to, with the vendor hidden behind it.

// Own the orchestration layer; rent the model behind an interface. Swapping
// vendors — or a self-hosted model for a managed agent — is then a one-file
// change, not a rewrite. This boundary IS the build-vs-buy insurance policy.
interface ModelProvider {
  complete(input: { system: string; messages: Msg[] }): Promise<string>
}

// Vendors are swappable infrastructure. Sonnet 5 today, whatever prices best
// next quarter — the rest of the app never learns which one it is.
const anthropic: ModelProvider = {
  complete: ({ system, messages }) =>
    callClaude({ model: 'claude-sonnet-5', system, messages }),
}

// The orchestration you OWN: retrieval, prompt assembly, budget, eval. This is
// the differentiation and the switching cost. It stays yours, in your repo.
async function runFeature(userId: string, query: string, model: ModelProvider) {
  const budget = await reserveBudget(userId)        // your unit economics, enforced
  const context = await retrieve(query)             // your domain knowledge, encoded
  const system = buildPrompt(context)               // your product's actual behavior

  const answer = await model.complete({ system, messages: [{ role: 'user', content: query }] })

  await recordSpend(userId, budget)                 // metered by you, not a vendor
  return answer
}

// Buying a managed agent means deleting runFeature and trusting a black box to
// own retrieval, prompt, budget, and eval. Fine for a commodity. Never for the
// one capability that is the reason your product exists.

What this means for a founder

The three-layer split turns a vague "should we build or buy AI" into three concrete calls you can make in a single meeting. For each AI capability, ask which layer it lives in. The model: buy, always. The surface: build, always. The orchestration: build it thin if the capability is your differentiation, buy it only if the capability is a commodity you would be embarrassed to claim as a moat. A support-ticket summarizer is a commodity — buy it. The reasoning engine that makes your product do the one thing nobody else does — build it, and keep the model swappable underneath.

Two numbers decide the close calls. The first is switching cost: when your vendor changes its billing — and it will; Anthropic split Agent SDK billing into a metered credit pool in June — how many weeks would it take you to move? If the answer is "we can't," you did not buy a feature, you bought a dependency. The second is unit economics: does the per-session cost of a bought runtime survive contact with your pricing at scale? If a metered agent costs more per session than the margin that session earns, buying it is a growth tax that gets worse with every new user you add.

The three-layer test

Run any AI feature through five questions before you write a line of code or sign a contract:

  1. Which layer is this — model, orchestration, or surface? Model: buy. Surface: build. Orchestration: keep going.
  2. Is this capability our differentiation or a commodity? Differentiation: build it thin. Commodity: buy it.
  3. Can we name the failure mode we own? If a bought agent hands a user a wrong answer, is that acceptable to our brand? If not, we cannot outsource it.
  4. What is our switching cost if the vendor changes price or closes the API? Measure it in weeks. More than a quarter means we are too coupled to call it a purchase.
  5. Do the unit economics survive scale? Model the per-session cost — tokens plus any runtime meter — against per-session revenue at 10x today's volume. If it inverts, buying is a tax.

If a capability is orchestration and differentiation and a failure mode you own and a switching cost you can't stomach and economics that break at scale, you build it. That is not most features. It is the one or two that are the reason your product exists.

My perspective

I make this call the same way on every engagement. On chays.ai the model is bought and swappable, but the orchestration — persistent, tiered memory that carries context across a fractional-CTO engagement — I built myself, because it is the entire differentiation and a metered third-party runtime between me and every session would have made the unit economics indefensible. On Freya Coach the split is identical: bought model, built-thin RAG orchestration, fully built coaching surface. I have never regretted building the orchestration layer. I have several times regretted a bought integration that quietly became a dependency I could neither price nor replace.

This is the same discipline I have argued from two other directions — that the 2026 fractional CTO is a person plus an agent team rather than a tool subscription, and that when a vendor moved Agent SDK billing behind a metered cap, the teams that had built their own orchestration barely noticed. Owning the layer in the middle is what makes a vendor change a shrug instead of a fire drill. That judgment — what to build, what to buy, and where to draw the boundary — is the agentic engineering work I do for teams shipping AI into production.

Recommended action this quarter

List every AI feature you ship or plan to. Tag each one: model, orchestration, or surface. For the orchestration items, mark differentiation or commodity. You will almost certainly find one capability you are about to buy that is actually your moat — pull it back in-house while Sonnet 5's introductory pricing makes building cheap. And you will find a commodity or two you are over-building — hand those to a vendor and reclaim the time. The goal is not to build everything or buy everything. It is to own the layer that makes you different and rent the rest.

Deciding what to build and what to buy?

If you are about to buy an AI capability that might be your actual differentiation — or build one a vendor does better — that is exactly the call I help founders get right. Book a time and we will run your AI roadmap through the three-layer test.

Book a Time
#Build vs Buy#AI Strategy#Fractional CTO#Founder Strategy#Unit Economics

Keep reading