Is It Cheaper to Build or Buy AI? The Arithmetic, With Every Input Stated

Why is "cheaper" the wrong first question?

Because it is incomplete in three ways, and the answer changes with each one.

Cheaper per what unit? Per licence seat, per run, per document, per completed task. A platform at a flat monthly fee and a build with a per-call cost cross over at a volume, and the crossover is the answer to a question nobody asked precisely.

At what volume? The comparison inverts between a few hundred runs a month and a few hundred thousand, because one option is a fixed cost and the other is a variable one.

Over what horizon? A three-year comparison is dominated by different lines than a one-year one: implementation and exit are front- and back-loaded, change requests and review minutes compound in the middle.

"Cheaper" becomes a number the moment the unit, the volume and the horizon are written down. Without them, the same two options can be defended in either direction by people who are both being honest.

I have priced this decision on both sides — as the person quoting a build and as the second opinion on someone else's shortlist — and the arithmetic below is the version I would defend in a room. Every input is a placeholder, because your loaded rates and volumes are yours and mine would only mislead you.

What are the five lines the comparison usually omits?

First-year prices are quoted; these are the lines that decide the three-year outcome, and they are omitted because they belong to nobody in particular.

The first line does the most damage. On the workflows I have scoped, human handling of the cases the system declines runs an order of magnitude above the inference cost, and every quote prices the inference line because that is the line the vendor controls. The procurement version of that asymmetry is a set of questions; here it is a line in a model.

What are the inputs, and what is the output?

Five inputs produce two outputs worth having: fully loaded cost per completed task over three years, and the volume at which the two paths cross.

The output for each path:

three_year_cost =
      volume × 36 months × per_run_cost
    + platform_fee × 36
    + exceptions × review_minutes/60 × loaded_rate × 36
    + build_weeks × weekly_rate          (built path)
    + 0.2 × build_cost × 3               (maintenance, built path)

cost_per_completed_task = three_year_cost ÷ (completed tasks over 36 months)

With the placeholders above, the built path's three-year cost is dominated by its first and third lines: about [$2.6M] of review time against the [6 weeks × $9,000 ≈ $54,000] build and its [~$32,000] of accumulated maintenance. That ratio is the reason this model is worth building: the decision being argued about is roughly two to four per cent of the money in the table, and the rest is a line nobody prices.

Where is the break-even?

Divide the build's fixed cost by the per-run saving to get the volume at which building starts to pay.

break_even_runs = build_cost + first_year_maintenance
                  ÷ (platform_per_run − your_per_run_cost)

Two properties are worth internalising. The break-even is expressed in runs, not months, so a low-volume workflow can take years to reach it while a high-volume one passes it in a quarter. And the saving per run has to include the exception line, because a build whose abstention rate is worse than the platform's is not cheaper at any volume — it moved cost from a per-run invoice into a queue.

That third row is the most common honest answer for a bespoke build: the platform is not expensive per run, it is expensive in human attention, and the reason to build is control of the exception path rather than the unit price.

Which lines dominate at each scale?

Notice that the middle row is where most mid-market companies actually sit, and it is the row where the decision is neither — the money is in the exception path, which is a design question rather than a procurement one. That is also why the comparison so often ends in the hybrid described below.

How do you price the build honestly?

Six line items, and a proposal that omits any of them is not comparable with a quote.

Maintenance is not optional and is usually underestimated: budget 15–25 per cent of build cost per year for model changes, schema drift, dependency upgrades and the quarterly re-scoring. A build with no maintenance budget is a build that will be switched off quietly in year two.

What if the answer is "both"?

It usually is, and the split is not a compromise. Buy the model and, if it earns its fee, the runtime; build the tool boundary, the approval rule and the evaluation set. That leaves the three properties worth paying for in-house — the semantics of your business, the ability to prove a regression, and the evidence trail — while the fast-moving layers stay someone else's problem.

That division is argued out in the four boundaries of an agent purchase, and the tool layer that most deserves to be yours is the MCP server you write yourself. The cost unit that keeps the whole comparison honest after go-live is cost per completed task, because it is the only one that puts the human line in the numerator.

The three-sentence version

Cheaper per completed task, at current volume, over three years — including the review minutes when the system declines a case. At [4,200] a month the build's break-even is about [three years] on per-run cost alone, which improves to [four months] at [40,000] a month, and the exception path improves the build's case before the unit price does. The proposal's recurring line is [$X] a month, of which [80] per cent is human handling, not software.

Those three sentences are the whole analysis, and each one can be checked by somebody who was not in the meeting. What usually decides the room, though, is not the arithmetic — it is whether the process is a source of advantage and whether a named person will still own it in year three. The arithmetic decides the scale at which that answer is also the cheap one, which is why it belongs in the proposal even when it is not the argument that wins.