The cleanest sourcing path for most AI capabilities in 2026 is buy-then-build. Buy the capability initially because the volume is too low to justify build, the buy options are mature, and the time-to-value matters more than long-run unit economics. Absorb the capability in-house later, when one or more of three triggers fires: the cost crossover (volume has scaled to where the buy bill exceeds the cost of running it in-house plus a margin for risk), the lock-in concern (the capability has become strategic enough that vendor dependency is unacceptable), or the differentiation need (the capability needs to do something the vendor will not or cannot do for you specifically). The progression works because it captures the optionality of buy at low volume and the leverage of build at high volume, without forcing the org to commit to either at the moment of decision. The mistake most orgs make is treating buy-versus-build as a one-time choice rather than as a sequence with explicit exit criteria written at the moment of buy. This piece names the progression, the three triggers, and the migration playbook.
This applies the AI build-vs-buy-vs-hire decision matrix for 2026. The matrix’s principles describe the sourcing decision; this piece operationalizes the most common sequence; start buy, end build; that the principles produce in practice.
Why buy-then-build is the dominant 2026 sequence
Three conditions make buy-then-build the right default. First, buy options are mature. Cohere ships production-grade RAG; Anthropic’s Skills cover a broad capability surface; OpenAI’s Agents SDK runs the loop layer; Pinecone, Weaviate, and Turbopuffer cover vector indexing. The buy market in 2026 is roughly where SaaS was in 2014; enough credible options that buy is a low-risk default. Second, foundation model unit economics are still moving; token costs fell 60-80 percent since 2024 and continue. Building infrastructure to optimize against today’s costs may be obsolete by ship date; buy preserves the option to capture future declines. Third, low-volume use cases are economically marginal for build. Fixed cost of running an AI capability in-house; eval suites, observability, on-call, security review; is $300K to $1M annual capacity-equivalent. A use case generating $50K of vendor spend does not justify the overhead.
The sequence is buy-now to capture options-value, build-later when the threshold is crossed. Orgs that build first end up with infrastructure against last year’s economics; orgs that buy first and rarely re-evaluate end up with vendor bills grown 10-50x without anyone noticing the crossover.
Trigger 1: cost crossover
The hard trigger: vendor bill exceeds in-house cost plus a margin for risk. In-house cost is engineering capacity (0.5 to 2 FTE depending on complexity), infrastructure (compute, storage, model API spend), eval/observability overhead (often absorbed by the platform team; see the hub-and-spoke org piece), and on-call. For most AI capabilities the in-house total is $400K to $1.2M annually. The crossover happens when vendor bill crosses 1.5x to 2x in-house cost; the multiplier is the risk margin.
Common crossover points: RAG and retrieval at $300K to $800K vendor spend; agent orchestration at $200K to $500K (highest-leverage build per the matrix’s fourth principle); embedding at $150K to $400K for high-volume workloads; eval harness at $50K to $150K (plumbing per the AI plumbing-vs-moat piece). The crossover threshold is workload-specific; the rule is to write it down at buy time and review quarterly. Orgs that do not write the threshold cross it without noticing.
Trigger 2: lock-in concern
The strategic trigger: the capability has become strategic enough that vendor dependency is no longer acceptable, regardless of cost. Four conditions can fire it: capability is critical-path for the product (dependency creates unacceptable risk); vendor roadmap diverges from org needs (trajectory unfavorable even if current cost is fine); contract terms become unacceptable (multi-year minimums, aggressive renewal pricing, restrictive data terms); vendor itself is at risk (acquisition, financial instability, strategic pivot).
The lock-in trigger is harder to diagnose than cost because it is often subjective. The discipline: name the lock-in risk explicitly at buy time and review quarterly; what would have to be true about the vendor for the org to want to migrate, and how close we are to that condition.
Trigger 3: differentiation need
The product trigger: the capability needs to do something the vendor will not or cannot. Three patterns: workload-specific behavior (vendor’s general-purpose product underperforms on the org’s specific distribution; vendor will not customize for one customer); integration depth (capability needs vertical integration with internal systems the vendor’s horizontal API does not support); data residency or governance (regulated industries where the vendor’s deployment model is structurally incompatible with compliance posture).
The differentiation trigger is the rarest but produces the highest-conviction migrations. When build is justified by differentiation, the org typically has a clear roadmap for what the in-house version does that the vendor does not, making migration scope concrete from day one.
The exit criteria written at buy time
The discipline that distinguishes orgs that execute buy-then-build well from orgs that drift into buy-forever is writing the exit criteria at buy time. Not after the vendor has been in production for two years and the bill has 10x’d; at the moment of buy.
The exit criteria document has four sections.
Cost crossover threshold. The vendor spend, the in-house cost estimate, and the multiplier (typically 1.5 to 2x). When vendor spend crosses the threshold, the migration conversation starts. Numerically specified.
Lock-in conditions. The list of vendor or contract conditions that would trigger migration regardless of cost. Specific to the capability and the vendor.
Differentiation conditions. The list of capabilities the vendor does not currently provide and is unlikely to provide, that would justify migration if the org needs them. Specific to the workload.
Migration scope estimate. The rough scope of the migration if it became necessary today; number of engineering weeks, dependencies, expected timeline. Updated quarterly so the estimate stays current.
The document is reviewed quarterly, owned by the architecture group (per the matrix’s first principle of a capability ledger), and consulted at most contract renewal. The vendor relationship has a built-in expiration logic; the only question at renewal is whether the trigger has fired yet, not whether the vendor relationship is permanent.
The migration playbook
Five phases over 6 weeks to 9 months depending on complexity:
- Phase 1 (weeks 1-3): scope the build. What does the in-house version need to do? What does it skip from the vendor’s feature set? Output is a build spec; not a clone, a workload-tailored capability.
- Phase 2 (weeks 4-8): stand up parallel. Build in production-adjacent infrastructure. Wire to eval harness. Run shadow mode against production traffic.
- Phase 3 (weeks 9-14): validate. Run eval comparisons, identify quality gaps, iterate until in-house meets or exceeds the vendor. Longest, least predictable phase.
- Phase 4 (weeks 15-20): cutover. Migrate traffic in stages; 5%, 25%, 50%, 100%. Monitor eval scores; roll back on regression.
- Phase 5 (weeks 21-24): vendor wind-down. Reduce vendor spend, exit contract, archive integration code, update capability ledger.
Total: typically 5 to 6 months for moderate-complexity capabilities (RAG, embedding, eval harness). Foundation model self-hosting is much slower (12-18 months) and is rarely the right migration target; most orgs continue buying foundation model API access even after building everything else.
What to keep buying after the migration
The migration is partial, not total. Even after building the workload-specific layer, most orgs continue to buy:
- Foundation model API access (the matrix’s third principle).
- Observability and tracing (often hub-managed but vendor-served; Langfuse, Helicone, Arize).
- Eval harness (per the AI plumbing-vs-moat piece).
- Agent framework loop (the inner loop, not the orchestration on top).
- Vector indexing (most orgs continue buying managed indexing even after building the retrieval logic on top).
The migration is from a vertically integrated buy to a layered architecture where the high-leverage middle layers are built and the low-leverage substrate layers continue to be bought. This is the steady-state architecture that the matrix’s principles produce; buy-then-build is the path that gets there from a buy-everything starting point.
Common failure modes
Migration without exit criteria written at buy time. The conversation becomes a quarterly debate without a defined trigger; the decision drifts, the bill compounds, the migration happens 18 to 24 months late.
Migration triggered by cost alone in a non-commodity category. Cost is the easy trigger but wrong for capabilities still differentiated in the market. Migrating away from a vendor that is genuinely better produces an underperforming in-house capability; cost saving is real but quality loss is larger.
Premature migration before the workload has stabilized. Building against a workload still being defined produces infrastructure that gets rebuilt when the workload settles. Migrate when the workload has been stable for 6 to 12 months.
Failure to absorb operational overhead. The build saves vendor spend but adds engineering capacity, on-call, eval ownership, incident response. Orgs that don’t staff the overhead end up technically functional and operationally fragile.
Frequently asked questions
What if the trigger fires for a capability we did not write exit criteria for?
Write the criteria now, retroactively. The exercise is the same: cost analysis, lock-in assessment, differentiation gap. The migration is the same. The only difference is that the conversation about whether to migrate has more political surface area because no one wrote down what should trigger it.
How do we know when the workload is stable enough to migrate?
Roughly, when the eval suite has not changed materially in 6 months and the volume is within 30 percent of where it has been for 6 months. If either is still moving, the migration target is still moving.
Should we usually run the in-house version in shadow mode before cutting over?
Yes, except for capabilities where shadow mode is operationally infeasible (capabilities that have side effects, capabilities that are too expensive to run in parallel). For pure-read capabilities like RAG and embedding, shadow mode is free and catches quality regressions before they hit production traffic.
What if the vendor offers a price cut to prevent migration?
Common scenario. The price cut is welcome but does not change the lock-in or differentiation triggers. If the migration was triggered by cost alone, the price cut may be sufficient to defer; if it was triggered by lock-in or differentiation, the price cut does not change the strategic case. The discipline is to make the decision against the trigger that fired, not against the latest negotiation.
How does this interact with multi-year vendor contracts?
The contract term shapes the timing, not the decision. If a multi-year contract is mid-term and reversal-cost is high, the migration may run in parallel with the contract for the remaining term, with the org running down the vendor while the in-house version absorbs new workload. The exit criteria document anticipates this; the migration scope estimate includes the contract overhead.
What about buy-then-build progressions inside an existing in-house stack?
Possible. A capability that was built in 2024 with a custom eval harness can migrate to a 2026 buy harness; the progression runs the other direction (build-then-buy) when commoditization has caught up. The decision logic is the same: triggers, exit criteria, migration playbook. The full guide to that direction is in the AI build-then-buy progression piece.
How often should the exit criteria document be reviewed?
Quarterly. Aligns with the matrix’s seventh principle of quarterly re-litigation. Quarterly is frequent enough to catch the cost crossover before it overshoots and infrequent enough that the review does not become routine paperwork.
What if the buy vendor gets acquired by a competitor or strategic adversary?
Lock-in trigger fires. The new ownership changes the vendor risk profile, often unfavorably. The migration timeline compresses; the playbook is the same but the calendar tightens. Orgs that wrote exit criteria at buy time can move; orgs that did not are scrambling.
What’s the relationship to the AI capability ladder?
The capability ladder gives the default verb under 2026 conditions. The buy-then-build progression operationalizes the common case where the default verb is buy and the trajectory is toward build-as-volume-scales. The ladder is the snapshot; the progression is the movie. The full ladder is in the AI capability ladder piece.
Key takeaways
- Buy-then-build is the dominant AI sourcing sequence in 2026: buy initial capability, absorb in-house when one of three triggers fires.
- The three triggers are cost crossover (vendor bill exceeds in-house cost plus a 1.5x to 2x risk margin), lock-in concern (capability becomes strategic), and differentiation need (workload requires what vendor does not provide).
- Exit criteria are written at buy time, not after the bill has compounded. The document names the threshold, the lock-in conditions, the differentiation conditions, and the migration scope.
- The migration playbook is five phases over 5 to 6 months: scope the build, stand up parallel, validate, cutover, vendor wind-down.
- The migration is partial; foundation model APIs, observability, and eval harness continue to be bought even after the workload-specific layer is built in-house.
The discipline that separates orgs that execute buy-then-build well from orgs that drift into buy-forever is writing the exit criteria at buy time and reviewing them quarterly. Without the discipline, the vendor relationship becomes permanent by default; with the discipline, the relationship has a built-in expiration logic and the migration happens at the right moment, not 18 months too late.
Arthur Wandzel
