Build vs. Buy for AI Features: A Decision Framework That Survives Contact with Reality

Most build-vs-buy decisions for AI are settled in the meeting by whoever speaks with the most confidence, not by whoever has priced the trade-offs. That is how you end up paying per seat for a workflow you could own, or maintaining a fine-tuned model that does what an API call does for a tenth of the cost.

The question is never build or buy. It's build what, buy what.

Treat "should we build or buy AI" as a single yes-or-no and you have already lost. Every AI feature is a stack: a base model, an orchestration layer, retrieval or tools, evaluation, a user interface, and the connective tissue that binds all of it to your actual data. You do not make one decision about that stack. You make five or six, and the right answer is almost always different for each layer.

The base model is a commodity you rent. The interface is table stakes. But the part that reads your ticket history, applies your refund policy, and writes back to your system of record is not something a vendor can hand you off the shelf, because they do not have your history, your policy, or your system of record. So the useful version of the AI build or buy decision is a sorting exercise: which layers are commodity, which layers are you.

Locating your moat: proprietary data and workflow vs. commodity capability

Draw the line by asking a blunt question of each component: if a competitor bought the exact same product tomorrow, would they be as good as you at this? Text generation, embeddings, speech-to-text, OCR — the answer is yes. Those are capabilities, and capabilities converge across every provider within a quarter or two. Buy them.

The answer flips the moment a component touches something only you have. Your seven years of resolved support tickets, labeled by which resolution actually stuck. The unwritten rules your best account manager uses to route a lead. The specific shape of your data and the specific sequence of your workflow. That is where AI product strategy lives, because that is the part a vendor cannot replicate by signing a bigger check.

A concrete case. A B2B support team wanted AI triage across roughly 900 inbound tickets a week. The classification — bug, billing, feature request, churn risk — is a commodity; any decent model does it. But the value was in routing churn-risk tickets to a senior rep within the hour, and "churn risk" was defined by patterns buried in their own closed-won and closed-lost records. The model was rented. The definition of what mattered, and the routing logic around it, was theirs to build. Getting that boundary right is the whole game.

The true cost of buying: lock-in, per-seat pricing, and a roadmap you don't control

Buying is faster and the sticker price looks honest. The costs that hurt are the ones not on the invoice. Per-seat pricing that felt cheap for a pilot of 12 people becomes a line item you notice at 400 seats, and by then the tool is wired into everyone's day and switching feels impossible. That feeling is the product working as designed.

Vendor lock-in with AI is sharper than with ordinary SaaS because the intelligence hides where you cannot inspect it. Your prompts, your evaluation data, and your accumulated corrections often live inside the vendor's system in a format you cannot export. Leave, and you leave the tuning behind. Then there is the roadmap. When the model underneath a bought feature changes — and it will, on the vendor's schedule, not yours — your carefully tuned behavior shifts and you find out from a user, not a changelog. You are renting someone else's priorities.

None of this means don't buy. It means price the exit before you sign. Ask where your data lives, what leaves with you, and what a 3x seat count costs. If those answers are vague, that vagueness is a cost.

The true cost of building: evals, maintenance, on-call, and model churn

Building is where people underestimate by the widest margin, because the demo is the easy 80% and the invisible 20% is the actual job. A prototype that classifies tickets well in a Tuesday demo is not a system. The system is everything that keeps it working on a Sunday at 2 a.m. when a model update quietly changes the output format.

The real bill has four line items nobody budgets for. Evaluations: you need a labeled set and a harness that tells you whether a change made things better or worse, or you are flying blind. Maintenance: prompts rot as your data and edge cases drift. On-call: an AI feature in production is a production system, with the pager to match. And model churn — the base model you built on gets deprecated or repriced, and you re-tune against its replacement. That last one is a recurring tax, not a one-time port.

Buy the commodity. Build the thing that touches your proprietary data and your workflow, because that is the only part a competitor can't also buy.

When I built Ledger, an invoice-extraction tool, the model reading the document was the least interesting part. The engineering that earned its keep was the math-validation layer that caught when line items didn't sum to the stated total — a guardrail the base model will never provide, because it has no stake in your books being right. That is the shape of a good build: thin where the market is strong, thick where your correctness lives.

The hybrid that usually wins: buy the model, build the glue and guardrails

For most teams the honest answer is a hybrid, and the split is predictable. Rent the intelligence through an API — you get frontier capability with zero training cost and someone else's on-call for the model itself. Build the thin layer that makes it yours: retrieval over your data, the guardrails that enforce your policy, the eval set that defines "good" in your terms, and the write-back into your systems.

This is the pattern behind the systems I ship. Lumen answers plain-English questions against a database by generating SQL — the language model is rented, but the schema grounding, the query validation, and the safety rails that stop a destructive statement are built. (The demo runs on SQLite; the production pattern generalizes to whatever warehouse you actually use.) Verba does the same for documents: bought embeddings and a bought model, built retrieval and citation logic. The model is interchangeable. The glue is the product.

A scorecard you can fill in during one meeting

You do not need a two-week study. Score each layer of the feature on five questions, one point each, and let the totals sort themselves:

For each layer (model, retrieval, orchestration, UI, write-back):

1. Does it touch proprietary data only we have?      (+1 build)
2. Is it core to how we win, not just table stakes?  (+1 build)
3. Would a competitor's off-the-shelf copy match us? (+1 buy)
4. Is a mature vendor already solving exactly this?  (+1 buy)
5. Can we staff the eval + on-call to run it well?   (+1 build / else buy)

3+ build  -> build it
3+ buy    -> buy it
split     -> buy the model, build the layer that scores "build"

The scorecard's real job is to force the argument out of the abstract. "We should build our own AI" dissolves into "we should build the routing logic and the eval set, and rent everything else," which is a decision you can actually staff and defend.

Revisiting the decision: what should trigger a rebuild or a switch

The decision is not permanent, and pretending it is causes half the pain. A buy becomes a build candidate when the vendor's roadmap diverges from yours, when per-seat cost crosses the salary of the engineer who'd own the alternative, or when the feature drifts from convenience toward core differentiation. A build becomes a buy candidate when a vendor matures past your in-house version and you are maintaining commodity infrastructure out of pride.

Set the trip-wires in advance so the review is a calendar event, not a crisis: a cost threshold, a switching-cost estimate you refresh yearly, and a note of which vendor moves would force your hand. AI implementation cost is a moving target, and the model churn underneath both options guarantees the ground shifts. The teams that stay ahead re-ask the question on a schedule instead of waiting for a bill or an outage to ask it for them.

Buy the commodity, build your moat, and rent the frontier in between. The company that knows exactly which of those it is doing, and why, out-executes the one still arguing build versus buy as if it were one question.