Build vs Buy AI: The Cost Comparison That Includes Year Two

Quick answer: Year-one build-versus-buy comparisons are close enough that either side can win them with reasonable assumptions. Year two is where they separate, because building carries seven recurring costs that do not exist in year one: model migrations, evaluation harness upkeep, drift monitoring, on-call load, guardrail maintenance, dependency churn, and key-person risk. Price those explicitly, state your assumptions, and the comparison stops being an argument about salaries.

Every vendor total-cost-of-ownership deck ends at go-live. This is not dishonesty so much as convenience: year one is the only year both sides can model with any confidence, and it happens to be the year where the build case looks strongest, because the work that keeps a system alive has not started yet.

If you are being asked to justify building rather than buying, the comparison you take to a finance review has to survive someone asking "and then what happens in month fourteen?" Here is that answer, as line items.

The year-one comparison you already have

It usually looks like this, and it is not wrong so much as incomplete.

Building: two to four people, some infrastructure, a first production release somewhere between month four and month twelve depending on how much of the problem is novel. Buying: a subscription, an integration project, a first production release in weeks.

Both sides then argue about salary numbers. That argument is unwinnable and beside the point, because the number that decides this is not the salary — it is how many of those people are still working on this system in month eighteen, and what they are doing.

The seven costs that only appear after the first release

These are the line items that do not exist in a year-one plan and are entirely real by month fourteen. Each one is small on its own. Together they are usually the decision.

1. Model migrations. Providers deprecate model versions on their own schedule, not yours. A migration is not a string change: prompts that were tuned against one model behave differently on the next, output formats shift at the margins, and anything downstream that parsed those outputs has to be re-verified. Budget for at least one significant migration a year per surface, and treat it as a week or two of engineering plus a full evaluation re-run, not an afternoon.

2. Evaluation harness upkeep. The eval set you built before launch describes the world as it was at launch. New failure modes arrive from real usage, edge cases get discovered by customers, and the cases you originally wrote stop being the ones that matter. Someone has to keep adding cases, keep the expected outputs correct, and keep the harness runnable as the code around it moves. This is the line item most often left out entirely, and it is the one that decides whether you can safely make any change at all.

3. Drift and data monitoring. The distribution of inputs changes without announcing itself — a new customer segment, a new document format, a supplier who changed their invoice template. Detecting that requires instrumentation, thresholds, and a person who looks. Without it, quality degrades silently and you find out from a customer. The mechanics are covered in our note on AI observability.

4. On-call and incident load. Once an AI system sits inside a workflow, it is a production dependency with the same obligations as any other: a service level people rely on, a pager, a runbook, and someone who answers at 2 a.m. Teams routinely price the build and forget that they have added a rotation. If your existing on-call cannot debug a model output, you have added a specialised rotation, which is more expensive than a general one.

5. Guardrail and policy upkeep. New attack patterns appear, internal policy changes, and regulation moves. Prompt injection defences, output filters, PII handling, and retention rules all need revisiting on a cadence rather than once. If you operate anywhere with a governance requirement, this is a named responsibility, not a background task — see AI governance frameworks for what that scope looks like.

6. Dependency churn. The AI application stack moves faster than almost anything else in software. Frameworks change APIs, SDKs go through major versions, and the orchestration library you chose may not exist in the same form in eighteen months. This is ordinary maintenance, but at an unusually high rate.

7. Key-person risk. One person usually holds the model of how the system actually works. When they leave, you pay for the rehire, the ramp, and the context that was never written down. This is the cost most likely to be dismissed in a planning meeting and most likely to be decisive in practice, because it arrives all at once.

The table a finance review will accept

A cost table survives scrutiny when three things are true: every line has a named owner, every number has a stated basis, and everything excluded is excluded on purpose and said out loud.

Size each line as a fraction of a full-time engineer per year, then multiply by your own loaded cost. Fractions are more defensible than dollar figures because the reviewer can argue with the fraction, which is the argument you want to have.

At the low end of those ranges a single AI surface costs roughly 1.2 FTE a year to keep alive after it is built. At the high end, closer to 3. Put your own loaded engineering cost against that, add metered inference, and you have the build column. The buy column is the subscription plus roughly 0.2 to 0.4 FTE, because buying does not reduce your evaluation and monitoring obligation to zero — it only reduces it.

Two notes that make the table hold up. State the loaded cost you used and where it came from. And do not present a single number: present the low and high ends with what drives you toward each, because a reviewer who can see the sensitivity stops looking for the trick.

The three assumptions that actually decide it

Everything above is arithmetic. These are the judgements underneath it, and they matter more than the numbers.

How many AI surfaces will you run? Most of the year-two cost is fixed per team rather than per surface. An evaluation harness, a monitoring setup, and an on-call rotation serve the second and third surface at a fraction of the cost of the first. Buying scales close to linearly with surfaces; building amortises. If you can name five surfaces you will genuinely run within two years, the build case strengthens considerably. If you can name one and are hoping for more, it does not.

Where is your differentiation — in the model, or in the data and workflow around it? This is the question the older framing of this article got half right. If a better model measurably changes your outcome, that capability has to be yours. But for most operations problems the differentiation sits in the data you have and the decisions you have calibrated, not in the model itself, and both of those stay yours whether you build or buy. Be specific rather than aspirational: name the metric that moves if the model is better.

How much single-person dependency can you carry? A build that depends on one specialist is a real risk with a real price, and the honest way to carry it is to fund a second person or accept a documented exposure. Pretending it is not there is how organisations end up buying in a hurry eighteen months later, at worse terms.

Roughly: below two or three production surfaces, buying usually wins on year-two cost even when year one favoured building. Above that, the fixed costs start amortising and the build case improves. Run your own version of that break-even with your own numbers — it is a short calculation and it settles most of the argument.

What to leave out of the table, and say so

Three things belong in the discussion but not in the cost column, and naming them protects the rest of the table.

Opportunity cost of engineering time is real but not a cash line, and mixing it in gives a reviewer something to dismiss the whole table over. Raise it separately: what does this team not build while it builds this?

"We would have hired them anyway" is sometimes true. If those engineers exist regardless, the marginal cost is lower — but then say which other work they stop doing, or the argument is circular.

Salvage value. A build that gets abandoned leaves you with code and, more usefully, an evaluation set and a labelled dataset. Those keep value even when the system does not. Note it; do not let it become the justification.

Hybrid, priced properly

Hybrid usually reads as a way of avoiding the decision. Priced properly it is often the strongest position: buy the surface, and own the evaluation set, the labelled data, and the monitoring. That costs roughly the 0.2 to 0.4 FTE in the buy column above, keeps the assets that actually compound, and leaves you able to move if the vendor stops fitting.

The mistake is the reverse arrangement — building the surface while relying on someone else's evaluation of whether it works. That combines the higher cost with the weaker position. Whichever side you pick, keep the evaluation harness on your side of the line. The reasoning behind that is the same one described in why AI POCs fail and in our POC to production timeline: the ability to tell whether a change made things better is the capability worth owning.

FAQ

What does maintaining an AI system actually cost per year?

For a single production surface, plan on roughly 1.2 to 3 full-time-equivalent engineers a year after the build is finished, before inference costs. That covers feature work, one or two model migrations, evaluation harness upkeep, drift monitoring, on-call, guardrail maintenance, and dependency churn. The range is wide because it depends on whether inputs come from outside your control, whether you operate under a governance requirement, and whether your existing on-call rotation can debug model behaviour. Size each line as a fraction of an engineer and apply your own loaded cost rather than borrowing someone else's dollar figure.

Why do build-versus-buy comparisons usually favour building?

Because they are drawn at year one, which is the only year both sides can model confidently and the year in which the build side carries none of its recurring costs. Model migrations, evaluation upkeep, drift monitoring, on-call, and key-person replacement all begin after the first release. Extend the comparison to a second year with those lines priced explicitly and the two columns usually move much closer together, and frequently reverse for organisations running only one or two AI surfaces.

When does building AI in-house genuinely make sense?

When you will run several production surfaces rather than one, so the fixed costs of an evaluation harness, monitoring, and on-call amortise across them; when a measurably better model changes a metric you can name; and when you can fund more than one person who understands the system, so a resignation is a setback rather than an outage. If two of those three are absent, buying almost always costs less over two years, and the hybrid position — buying the surface while owning the evaluation set and the data — is usually stronger than either pure option.

What should a build-versus-buy cost table include to survive a finance review?

Named owners for every line, a stated basis for every number, and an explicit list of what has been excluded. Express effort as fractions of an engineer rather than dollars so the reviewer argues with the fraction rather than the salary assumption. Show a low and a high case with the drivers that push you toward each. Keep opportunity cost, the "we would have hired them anyway" argument, and salvage value out of the numbers and raise them separately, so that a disagreement about one of them does not invalidate the table.

Get unstuck

If you are weighing build versus buy for a specific system, we can help you price the year-two column against your own volumes and team. Applied AI Studio builds production systems and also advises teams who are better off buying one. Talk to us about your situation.