Build vs Buy for AI Features
6 min read · updated August 3, 2026
Build or buy is the wrong shape for this decision, because there are at least four places to draw the line and the answer is usually different at each one. Once you know which layer you are arguing about, the rest is arithmetic with about six terms in it.
It is not two options
Every AI feature sits on a stack, and “buy” can mean buying any prefix of it. Naming the layer first stops two people having confident opposite opinions about different questions.
| Layer | Description |
|---|---|
| 1 — buy the outcome | A finished product that does the job: a support suite with drafting built in, a meeting notetaker, a coding assistant. You configure it. You own no model code and no prompts, and you get whatever quality the vendor ships. |
| 2 — buy the platform, build the app | A vendor supplies retrieval, orchestration, evaluation and a console; your team writes the prompts, the workflow and the integrations. You own behaviour and not infrastructure. |
| 3 — build on a model API | Your code, your prompts, your retrieval, calling a hosted model over HTTP. You own everything above the model and nothing below it. |
| 4 — run the weights yourself | Open-weight models on hardware you rent or own. You now also own capacity planning, upgrades and utilisation, which is a different job with a different failure mode — and the arithmetic for that one step is a break-even in GPU-hours rather than seats. |
Most enterprise arguments that feel unresolvable are a layer-1 person talking to a layer-3 person. They are both right. The useful move is to price the same feature at two adjacent layers and compare, rather than to compare building at layer 3 with buying at layer 1 and declaring the gap enormous.
One asymmetry is worth naming before any numbers. Buying at layer 1 means the vendor decides when the model changes underneath you; the same feature can behave differently on a Tuesday for reasons you cannot inspect. Building at layer 3 means you decide, and you also carry the work of noticing when a provider changes a model on you. Neither is free. The difference is whether the surprise is yours to manage or yours to absorb.
The cost terms, defined
Six terms, and comparisons go wrong mostly because one side of the table is missing two of them. All figures below are annual.
BUY BUILD
L licence, per seat or platform I build cost: engineer-days * rate
C config / onboarding, one-off amortised over the life you expect
U usage overage above the plan M inference spend (metered)
A admin time to run it O ops: on-call, evals, migrations
X exit cost if you leave X exit cost if you stop
R risk reserve: the rework you will
do when a model or an API changesTwo of those deserve their definitions spelled out, because they are where the estimates are usually fictional.
- I is not the estimate the team gives you. Take their estimate for the working feature and add the parts that are not the feature: an evaluation set and harness, logging and cost attribution, an admin surface, a fallback path for when the model is unavailable, and the security review. Those are real days and they are the same days regardless of how clever the prompt turns out to be.
- O is a rate, not an event. Anything you build needs somebody who can answer “why did it say that” at 4pm on a Thursday. Budget it as a fraction of an engineer per month, forever, and be honest that it does not go to zero after launch.
Seats versus meters
The single most useful calculation in this decision, because it is the one that changes answer as you grow. A bought product is usually priced per seat per month; a built one is priced per unit of work. Those two curves cross, and the crossover is a headcount you can compute.
buy(N) = 12 * N * L_month + A build(N) = I/life + O + 12 * N * q * c N seats L_month licence per seat per month A admin time to run the bought tool, in money I/life build cost spread over the years you expect it to last O ongoing ops cost per year q requests per seat per month c cost per request Crossover: the N where buy(N) = build(N) N* = ( I/life + O - A ) / ( 12 * (L_month - q*c) )
Worked, with every input an assumption you should replace: L_month = $30, A = $12,000/year of administration, I = $180,000 of build amortised over life = 3 years, O = $60,000/year, and usage of q = 300 requests per seat per month at c = $0.01.
q * c = 300 * 0.01 = $3.00 per seat per month
L - q*c = 30 - 3 = $27.00 per seat per month of licence
that building avoids
N* = (60,000 + 60,000 - 12,000) / (12 * 27)
= 108,000 / 324
= 333 seats
At 100 seats: buy = $48,000 build = $123,600
At 333 seats: buy = $131,880 build = $131,988 (equal, to rounding)
At 1000 seats: buy = $372,000 build = $156,000Three things fall out of that shape and they generalise even though the numbers do not. First, building loses badly at small headcounts and the loss is not close — under a hundred seats the fixed terms swamp everything. Second, the crossover moves with q: heavy usage per seat pushes N* up, because metered inference stops being cheap relative to a flat licence. Third, the crossover is extremely sensitive to life. If the built feature is rewritten after eighteen months rather than three years, I/life doubles to $120,000 and N* moves out to about 519 seats. Argue about life before arguing about the model.
The term both sides leave out
Buyers omit A and X. Builders omit O and R. Some specifics for the ones that are genuinely easy to miss:
- Evaluation is a standing cost, not a project. A frozen set has to be re-run whenever the model, the prompt or the retrieval changes, and somebody has to look at the diffs.
- Model migrations arrive on the provider’s schedule. Deprecations, new versions, changed defaults. The work is small each time and it is not zero, and it is the main reason an abstraction boundary you can swap a provider behind is worth drawing early.
- Exit cost is real on both sides. Leaving a bought tool means exporting whatever it accumulated, in a format you have not seen. Abandoning a built one means someone still has to delete the data, revoke the keys and unpick the integration.
- The bought tool has an admin. Somebody provisions seats, answers questions, reviews the settings after every vendor release and handles the renewal. That is
A, it is usually a named person, and it is usually left out of the comparison entirely.
A decision rule, and when to revisit it
The rule that follows from the arithmetic, stated plainly: buy at the highest layer that meets your requirements, and move down a layer only when you can point at the specific requirement the layer above cannot satisfy. “We would like more control” is not such a requirement. “The data may not leave our tenancy”, “the output must be checkable against our own records” and “this is the product we sell” all are.
That last one is the genuine exception to the crossover maths. If the AI feature is the differentiating part of what customers pay you for, the comparison is not cost against cost; it is cost against owning your own roadmap, and a vendor’s priorities will never match yours indefinitely. Everywhere else — internal tools, workflow assistance, back-office automation — the arithmetic above is the whole argument.
Set a date to redo it. The inputs move: licence prices change, per-token prices have moved repeatedly and mostly downward, your seat count grows, and your usage per seat grows fastest of all once people find the feature useful. A decision made at 80 seats deserves rechecking at 300, and the arithmetic takes an hour.