Buy vs Build Under a Moving Frontier

Overview

The classic buy-versus-build analysis assumes a stable market: compare total cost of ownership, weigh control against speed, decide. It works when the thing you are buying will be roughly the same thing in three years.

AI capability is not stable, and that changes the analysis in a specific way. When a capability is improving rapidly, buying is usually right and the real question becomes what the switch will cost later. The decision is less about the vendor than about the seam.

Own what encodes your domain

The durable principle, and it survives the frontier moving.

Buy what is commoditising. Inference, embedding, vector storage, orchestration scaffolding. These are improving fast, being competed hard, and getting cheaper. Anything you build here is a depreciating asset: you will maintain it while the purchased equivalent improves past it.

Build what encodes knowledge only you have. Your evaluation set, your document corpus, the list of actions your system may take and their approval requirements, the measured facts about your own traffic. None of this can be bought, none of it depreciates when a model is replaced, and all of it is what makes the purchased components useful in your context.

This split produces a useful test: if a vendor could sell it to your competitor unchanged, buy it. If it only has value because of what you know, build it.

The consequence is that the valuable assets are not the clever parts. Modules 4 through 6 produced an evaluation set, a corpus strategy, a tiered action list and a cost model — unglamorous next to a well-engineered inference layer, and the only components that still have value after the next model generation.

graph TD
  A["<b>Commoditising fast</b><br/>inference, embeddings,<br/>vector storage"] --> C["<b>Buy</b><br/><i>building here<br/>depreciates</i>"]
  B["<b>Encodes what only<br/>you know</b><br/>evals, corpus, action list,<br/>your measured traffic"] --> D["<b>Build</b><br/><i>survives every<br/>model change</i>"]

  classDef com fill:#E8A33D,stroke:#C4832A,stroke-width:2px,color:#ffffff
  classDef own fill:#7D9A4E,stroke:#5F7A38,stroke-width:2px,color:#ffffff
  classDef buy fill:#5B8FB9,stroke:#4A7A9E,stroke-width:2px,color:#ffffff
  class A com
  class B own
  class C buy
  class D own

One test separates them: could a vendor sell this to your competitor unchanged?

Price the switch, not the vendor

Since the frontier moves, you will change a purchased component. So the question that deserves the analysis is what the switch costs, and that is a design decision rather than a procurement one.

Three costs to look at explicitly:

Interface coupling. How much of your code knows which provider it is talking to? A thin internal abstraction over a purchased capability is one of the few abstractions that reliably pays for itself, because the replacement is near-certain rather than hypothetical.

Data gravity. What accumulates inside the vendor that you would have to recreate? Embeddings can be regenerated at a known cost; fine-tuned weights cannot be moved at all. This is the sharpest difference between purchase options and the one most often ignored at selection time.

Behavioural coupling. The one that surprises people, and Module 7 covered it: your prompts, thresholds and evaluation expectations are tuned against one model’s behaviour. Switching invalidates that tuning, and the cost of re-establishing it is usually larger than the integration work. Your evaluation set is what makes this measurable instead of terrifying — which is another reason it belongs in the “build” column.

Open source as a third option

Not a middle ground but a distinct position with its own profile: no licence cost, full control, no vendor dependency — paid for in operational responsibility, and in your own engineers’ time, which is the resource the previous topics established you do not have.

Under zero spare capacity, self-hosting a capability that a vendor operates for you is usually the wrong trade regardless of its merits, and the honest reason to state is capacity rather than quality. Where it genuinely wins is when a constraint makes purchase impossible — a data-residency or contractual requirement no vendor can satisfy. That is a requirements question, not a preference.

State the reconsideration trigger

The rubric item, and the same discipline as Module 9’s reversal conditions: a buy-versus-build decision without a named trigger gets revisited either never or constantly.

A good trigger is observable and specific. Not “if the vendor landscape changes” but a named condition someone could check: a measured cost crossing a threshold, a capability becoming available in a cheaper tier, a residency requirement arriving from a contract, a measured plateau that only a different approach would break.

Four components, four calls, four triggers

The decision for the AI support platform, component by component.

Inference — buy, hosted, in-region. Decided in Module 4 and still right: commoditising fast, improving quarterly, and self-hosting would consume capacity that does not exist. Reconsideration trigger: if per-interaction cost at steady-state volume exceeds the modelled ceiling by a sustained margin, or if a contract arrives whose residency terms no provider can meet in a required region.

Vector storage and the retrieval layer — buy. A vendor could sell the identical thing to a competitor, which is the test failing cleanly in favour of buying. Trigger: if retrieval precision plateaus in a way that is attributable to the store’s capabilities rather than to the corpus — which Module 4’s work says is unlikely, since the corpus is the binding constraint.

The evaluation set, the corpus strategy and the tiered action list — build, and these are the real assets. None could be purchased: they encode nine years of support history, a specific regulatory position, and a measured model of this company’s own traffic. They also survive every model change, which is what makes the purchased components swappable at a bearable cost. No trigger — these are never outsourced.

The orchestration between the two services — build, narrowly, and this one is a genuine judgement call. Frameworks exist and they are improving. But the orchestration here is where the action tiers, the approval requirements and the degradation ladder live — which is domain knowledge wearing infrastructure’s clothing. The call is to build thinly and own it, while keeping the inference interface abstracted behind it. Trigger: if the orchestration grows past the point where it is mostly domain policy and starts becoming general-purpose plumbing, the plumbing half should be replaced with something bought.

The switching cost that is actually priced in. Behavioural coupling is the largest of the three and the least visible. The prompts, the confidence thresholds and the regression gate are all tuned against one model’s behaviour, and the eval set — about 300 cases, with the rep count Module 6’s noise-floor arithmetic corrected upward — is what converts a model switch from a leap of faith into a measurement. That is the single strongest argument for having built it.

Feeds the workbook

This is your buy-vs-build decision artifact, and the rubric requires a named reconsideration trigger. One per component, observable and specific.

Check your understanding

1. Apply the competitor test to three components of a system you know. Which calls does it reverse?
2. For one purchased component, what would switching actually cost? Which of the three costs is largest?
3. Write a reconsideration trigger someone could check without asking you.

---

→ The technical decisions are made. The rest of the job is the part nobody puts in a diagram. — Hard situations and the human texture