The build-then-buy progression is rare but it exists. The org builds a capability because no acceptable buy option is available at the moment of decision, then transitions to buy when the market matures, the in-house build no longer pencils against the new buy options, or the org’s strategic priorities shift away from owning the layer. The progression runs opposite to the more common buy-then-build sequence and applies in a narrow set of circumstances: capabilities at the frontier where the buy market is genuinely immature, capabilities where the org’s early build became the buy option (the org is the platform vendor), or capabilities where strategic priorities have shifted such that infrastructure work the org once invested in is now overhead the org wants to externalize. The sequence is rarer than buy-then-build because most 2026 AI capabilities have at least one credible buy option; the cases where build-then-buy is correct are specific and identifiable, but the number of capabilities where it applies is small. This piece names the three patterns where build-then-buy is correct, the externalization triggers, and the migration playbook for the reverse direction.
This builds on the AI build-vs-buy-vs-hire decision matrix for 2026. The matrix’s principles describe sourcing decisions in steady state; this piece operationalizes the rarer reverse-direction sequence; start build, end buy; that the principles produce when commoditization catches up to a capability the org built before the buy market existed.
Why the reverse direction is rarer
In 2026 the buy market for most AI capabilities is mature enough that buy-first is the default. Foundation models, vector indexing, embedding services, eval harnesses, agent loop frameworks, observability; most layer has at least two credible buy options. Build-first is correct only when one of three specific conditions holds, and even within those conditions the build-first decision is reversible by definition: the org commits to build, with the explicit understanding that buy options may emerge that change the analysis.
The reverse direction is harder than the forward direction because the in-house build accumulates weight that the migration has to undo. Engineers built it. Operations runs it. Eval suites are wired to it. Documentation references it. Migrating away from a vendor is technical work; migrating away from an in-house build is technical work plus institutional work. The reverse direction takes longer per equivalent capability and faces more political resistance.
That said, the reverse direction is correct when the conditions match. Three patterns dominate.
Pattern 1: frontier capability that commoditized
The most common pattern. The org built a capability in 2023 or 2024 because buy options were inadequate; by 2026 buy options have caught up. Examples:
- Custom eval harnesses. Many orgs built their own test runner in 2023 to 2024 because Promptfoo, Inspect, and Braintrust were too immature. By 2026 those products are production-grade; the in-house harness is now plumbing per the AI plumbing-vs-moat piece.
- Custom agent loops. Orgs needing multi-step agents in 2024 built their own loop and state management. By 2026 OpenAI Agents SDK, LangGraph, Pydantic AI, and AutoGen cover the loop layer.
- Custom observability. Orgs with high data residency built their own in 2024; by 2026 Langfuse, Helicone, and Arize offer compliance-friendly deployment.
- Custom prompt management. Vendors in this space have consolidated; buy options are credible.
Pattern 1 is the typical re-litigation outcome from the why 2024 decisions should be re-litigated piece. The verb at decision time was build because buy did not exist; the verb today is buy because the market caught up.
Pattern 2: the platform-company case
Less common but distinctive. Some orgs build AI infrastructure that becomes the buy option for the rest of the market; the org is the platform vendor. Examples:
- A foundation model lab whose internal training and inference infrastructure becomes its product.
- A retrieval startup whose internal RAG infrastructure becomes the API it sells.
- An eval-tooling company whose internal eval harness becomes the product.
For these orgs the build-then-buy progression looks different: the build is the strategic moat, and the org transitions from building for itself to selling to others. The internal capability stays in-house but its primary purpose shifts from internal use to external product. From the org’s standpoint there is no buy migration; from the broader market’s standpoint, the platform company’s emergence is what makes pattern 1 possible for everyone else.
The platform-company case applies to a small number of AI-native companies. It is named here because it is the engine that produces the buy options that pattern 1 migrates toward, and because some companies that think they are operating in pattern 1 are in pattern 2; they have a buildable capability that other orgs would pay to use. Recognizing the pattern correctly changes the strategic posture from “build for internal use, then migrate to buy” to “build as moat, then commercialize.”
Pattern 3: strategic deprioritization
The rarest pattern. The org built infrastructure for a priority that since shifted. Examples: an e-commerce company built fine-tuning in 2024 to differentiate on model quality, then shifted strategy to merchant-facing tooling; a media company built custom content moderation, then refocused engineering on subscription features; a SaaS company built embedded AI across a wide surface, then narrowed to one product line.
The capability is not commoditized in the market; it is deprioritized in the org. The build still works; the org just no longer wants to own it.
Externalization triggers
Three triggers, structurally parallel to the buy-then-build triggers but inverted in direction.
Trigger 1: buy market matures past parity. A buy option matches or exceeds the in-house capability on the workload’s eval criteria, at a unit cost that is not meaningfully higher than the in-house cost (and is often lower because buy aggregates demand across customers). The trigger fires when the buy is not just available but is at parity or better; pre-parity buy options are not migration targets.
Trigger 2: the in-house cost is no longer justified. Engineering capacity allocated to maintaining the in-house capability is needed for moat work elsewhere, and the buy option’s overhead is acceptable. The trigger fires when the org has identified moat work that is starving for capacity that could be released by externalizing the in-house capability.
Trigger 3: vendor risk has dropped to acceptable. The buy market for the capability has at least two credible providers, contracts are not abusive, and the vendor risk is comparable to or lower than the risk of running the in-house version (which has its own risks: key engineers leaving, security gaps, eval drift). The trigger fires when the vendor risk is no longer the binding constraint that justified the original build.
When many three triggers are present, the externalization is the right call. When only one is present, it is usually too early; the migration costs typically exceed the benefits unless multiple triggers are aligned.
The reverse-migration playbook
The migration runs in the opposite direction of buy-then-build but uses a similar five-phase structure.
Phase 1, weeks 1-3: scope the externalization. What capability is being externalized, to which vendor, with what feature delta? The scope explicitly identifies what the in-house version does that the vendor does not, and decides for each gap whether it is acceptable to lose, must be replicated on top of the vendor, or is a deal-breaker.
Phase 2, weeks 4-8: integrate the vendor. Stand up the vendor integration in production-adjacent infrastructure. Wire it into the org’s eval harness (whether the harness is hub or spoke per the hub-and-spoke org piece). Run shadow comparison against the in-house capability.
Phase 3, weeks 9-14: validate the vendor on the workload. Run eval comparisons. Identify quality gaps. Decide for each gap whether to accept the gap, build a thin layer on top of the vendor to close it, or abandon the migration if the gap is unacceptable.
Phase 4, weeks 15-22: cutover. Migrate traffic to the vendor in stages. Monitor eval scores and operational metrics. Roll back if regressions appear. The cutover phase is typically slower than the buy-then-build cutover because the in-house capability has more institutional dependencies (internal tools, custom integrations, on-call workflows).
Phase 5, weeks 23-28: in-house wind-down. Sunset the in-house capability, archive the code, redirect engineering capacity to the moat work that justified the migration. Update the capability ledger.
Total elapsed time is typically 6 to 7 months for capabilities of moderate complexity, slightly longer than the forward direction because of the institutional unwind. The hardest part is phase 5; decommissioning the in-house version; because the in-house capability often has long-tail dependencies that surface during decommission rather than during cutover.
What gets harder running this direction
Three things are genuinely harder than the forward direction.
Engineer attachment. Engineers who built the in-house capability often resist its decommission. The resistance is rational at the individual level (loss of expertise relevance, loss of ownership) and irrational at the org level (the migration is correct on the merits). Managing the resistance requires explicit conversation about role transition; the engineers who built the capability typically transition to either operating the vendor relationship or to the moat work the migration enables.
Eval gap closure. The in-house capability was built for the workload; the vendor was built for the market. The eval gaps from the workload-specific tail are real and have to be closed deliberately. Many migrations stall in phase 3 because the gap is larger than expected and the team has to decide whether to accept lower quality, build the gap-closing layer, or abandon the migration.
Reversibility cost. Once the in-house capability is decommissioned, reverting is expensive. The buy-then-build forward direction has natural reversibility (re-engage the vendor) for the first 6 to 12 months after migration; the build-then-buy reverse direction has limited reversibility once phase 5 completes. The discipline is to keep the in-house capability runnable (even if not actively running) for 3 to 6 months after vendor cutover.
Frequently asked questions
How do we know we are in pattern 1 versus pattern 2?
The diagnostic is whether other organizations in your market segment would pay for the capability. If the answer is yes; multiple other orgs have a similar use case and would buy a productized version; the org is in pattern 2 and should consider commercialization rather than externalization. If the answer is no; the use case is workload-specific to this org; the org is in pattern 1 and the migration is the right move.
Can the externalization be partial?
Yes. Many migrations externalize the substrate (model gateway, vector indexing, eval harness) while keeping the workload-specific layer (prompts, retrieval logic, orchestration) in-house. This is the same layered architecture as the buy-then-build endpoint, just arrived at from the opposite direction.
What if the vendor is at parity but more expensive?
Externalization can still be correct if the engineering capacity released by the migration is more valuable than the cost differential. The math is: vendor cost minus in-house cost equals capacity cost differential; engineering capacity released times moat-work value equals capacity benefit. If capacity benefit exceeds capacity cost differential, the migration is correct on cost grounds alone.
How does this relate to the AI commoditization argument?
The build-then-buy progression is the operational consequence of commoditization at the capability layer. The full argument is in why AI commoditization can reduce 60% of build decisions by 2027; this piece is what to do when commoditization catches up to a build decision the org already made.
What if the in-house capability is a competitive advantage?
Then it is not a candidate for externalization. The build-then-buy progression applies only to capabilities that are no longer differentiating; capabilities that are still differentiating stay in-house regardless of commoditization elsewhere. The decision is per-capability, not per-org.
How does this interact with the matrix’s principles?
The matrix’s principles apply to each decision in steady state. The build-then-buy progression is the workflow for transitioning from an old steady-state verb (build) to a new steady-state verb (buy) when conditions have shifted. The principles do not change; the verb produced by applying them does.
What about capabilities where the buy option is dominated by a single vendor?
Single-vendor lock-in is one of the conditions that should weigh against externalization. If the buy market has only one credible provider, the lock-in risk is high and may justify continuing the in-house build despite the apparent maturity. Externalization should target buy markets with two or more credible providers.
Can we run build-then-buy and buy-then-build simultaneously across different capabilities?
Yes, and most mature AI orgs do. Different capabilities are at different maturity stages; the right verb for each is what the matrix’s principles produce now, not a uniform org-wide stance. The org is running multiple progressions in parallel; the architecture group’s job is to keep track of which capability is on which trajectory.
Key takeaways
- Build-then-buy is rarer than buy-then-build but real, applying in three patterns: frontier capability that commoditized, the platform-company case, and strategic deprioritization.
- The externalization triggers are structurally parallel to the buy-then-build triggers but inverted: buy market matured past parity, in-house cost no longer justified, vendor risk dropped to acceptable.
- The reverse-migration playbook is five phases over 6 to 7 months: scope, integrate, validate, cutover, wind-down.
- The reverse direction is harder than the forward direction because of engineer attachment, eval gap closure on workload-specific behavior, and limited reversibility once decommission completes.
- Most mature AI orgs run buy-then-build and build-then-buy simultaneously across different capabilities; the verb per capability is what the matrix’s principles produce now, not a uniform org-wide stance.
The build-then-buy progression is the right call when commoditization, capacity reallocation, or strategic shift makes the in-house capability no longer the right verb. The discipline is the same as the forward direction: write the migration triggers explicitly, review them quarterly, and execute the migration when the triggers fire. Without the discipline, in-house capabilities accumulate as legacy that the org rarely quite gets around to decommissioning, even when the buy market has clearly caught up.
Arthur Wandzel
