Most teams settle this question by putting a monthly API invoice next to a one-off quote from an engineering firm. The two figures do not measure the same thing. An invoice grows every time the product succeeds. A quote lands once, then leaves a quieter bill running underneath it for as long as the system stays in production. Three years on, the ranking has often reversed — and the reversal is rarely about price.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
The two bills have different shapes
Paying per call is an operating cost that tracks usage. A pilot answering a few hundred requests a day costs so little that nobody in finance asks about it. The same system at full volume becomes a line item with an owner and a quarterly review. Nothing went wrong in between. The product worked, and the cost of serving it followed.
Building moves the money to the front. Salaries, data work and computation are spent before a single user sees a result. What comes afterwards is flatter, though never flat, because a model in production carries running costs that no statement of work mentions.
The decision reads like a comparison of totals. It is closer to a choice between two curves, and curves cross.
Year one answers almost nothing
Through the first twelve months, buying nearly always looks cheaper. Usage is low and the build has not been amortised. A team deciding at this point is reading the stretch of the graph where the outcome was never in doubt.
Year two is where the question earns attention. Usage has climbed, the per-call bill has stopped being invisible, and a built system has begun to show its maintenance load. Year three settles whether what you built is an asset or a liability — whether it still beats what anyone can now buy by signing up.
What a build costs after it is built
The engineering quote covers the model. It rarely covers what keeps the model honest.
Google's research team made the point a decade ago in a paper on hidden technical debt in machine learning systems, whose central illustration shows model code as a small box surrounded by much larger ones: data collection, feature extraction, serving infrastructure, monitoring, configuration. The proportions have not changed since.
An evaluation set has to exist before anyone can say whether a change improved anything, and somebody has to keep widening it as real users submit inputs nobody imagined. Labelled data ages. The spread of requests your customers produce this year is not the one they produced last year, and accuracy decays quietly rather than failing loudly. Retraining turns out to be a rhythm, not an event.
Serving is its own budget line. Inference capacity gets provisioned for peaks, watched, and paid for during the long hours it does nothing. Somebody carries the pager when latency climbs at four in the morning. Little of this work is visible from the outside, and none of it fits neatly into a fixed-price contract.
Teams that treat custom AI development as a project with a delivery date are the ones caught out in year two. Teams that treat it as a system with a permanent owner tend to budget closer to reality.
Buying has a long tail too
The bought route does not stand still either. Prices move in both directions. Models retire on the vendor's schedule rather than yours, and a replacement that scores higher on public benchmarks can behave worse on your particular task, which sends prompts and guardrails back to the workbench.
Rate limits shape architecture. Residency rules can rule a provider out of a market you wanted to enter. None of this is ruinous. All of it is work that arrives unannounced.
What locks a company in is seldom the contract. It is the accumulated prompt engineering, the evaluation harness tuned to one vendor's quirks, and the shape of the data pipeline feeding it. Those assets look portable on paper and prove sticky in practice, which is why the second migration tends to cost more than anyone budgeted for the first.
Price is the smaller half of the question
Set the arithmetic aside and a harder question sits underneath. Does this capability need to belong to you?
If a competitor can obtain the same result by opening an account with the same vendor, building it buys parity at a premium. If the task leans on data only you hold — your support history, your claims records, your catalogue — then what you build is a position rather than a feature, and the three-year total stops being the number that matters.
Latency and privacy move the line as well. Some work cannot leave the building. Some answers cannot wait for a round trip across the public internet. Constraints like these settle the matter before cost joins the discussion.
Photo by Mohammad Rahmani on Unsplash Where the line usually falls
Narrow, repetitive, high-volume work rewards building. The scope holds still, evaluation is tractable, and the saving on each call compounds into something worth the trouble.
Broad work with moving requirements rewards buying. Paying a premium per call costs less than paying a team to chase a specification that changes every quarter.
Most organisations land on both sides at once, which makes the sharper question not who wins but which pieces belong where.
Decide on a measurement, not a forecast
A three-year model built before launch is a guess wearing a spreadsheet. The volumes are assumed, the accuracy target is assumed, and the maintenance load is usually missing altogether.
A steadier sequence: ship the bought version, instrument it properly, and watch what usage does over two or three quarters. By then the real volume is known, an evaluation set has been assembled out of live traffic, and the part of the task the general model handles badly has made itself obvious. That part is the one worth building, and its value will be something you measured rather than something you estimated.
