Before an operator evaluates a single AI vendor, there is a prior decision that determines which vendors even belong on the list: build the capability in-house, buy a working result on a defined process, or hire someone to do it. The question is the old make-or-buy choice applied to a new input, and it is answerable. It turns on three quantities a CFO or COO can estimate from public data. The first is the cost and scarcity of the talent required to build. The second is the time from a decision to a working result. The third is the rate at which internal builds stall before they reach production. Get those three numbers roughly right and the decision mostly makes itself.
What the talent actually costs
Start with the build path, because it is the one operators tend to underprice. The compensation aggregators disagree on what a machine-learning or AI engineer costs because each samples a different slice of the market, but none of them make the role look cheap. Stack Overflow's 2025 Developer Survey puts the median US salary for the role at $189,500, third highest among the roles it surveys, and Levels.fyi, whose submitted offers skew toward large technology companies, puts median US total compensation at $272,500. These are aggregator medians, not a single audited figure, and they should be read together as a range. The Bureau of Labor Statistics, the closest government reference, does not maintain a distinct occupation code for the machine-learning engineer, so the public benchmark for this specific role is the private aggregators rather than the federal wage survey, which is itself a fact worth knowing about how new the role is.
Base compensation is not the cost. The fully loaded cost of an engineer includes benefits, payroll taxes, equipment, management overhead, and the months of ramp before the person produces anything useful, and on top of that sits attrition risk. If the one person who understands the system you built leaves, the capability leaves with them. For a single hire, the all-in number an operator should hold in mind runs meaningfully above the headline compensation figures, and a real capability is rarely one person.
Scarcity, not just price
Price is only half the talent problem. The other half is whether you can hire at all. Bain & Company projected in early 2025 that demand for AI jobs in the US could surpass 1.3 million over the following two years, with the supply of qualified people on track to reach fewer than 645,000, in an analysis that shows AI-related job postings growing 21% annually since 2019 and compensation growing 11% annually over the same period. Pay is high because supply is short relative to demand. An operator competing for that talent is competing against technology firms and well-funded startups whose entire business is the thing you are trying to staff as a side capability. A mid-market manufacturer or a service firm posting a senior ML role is not the marginal employer in that market, and the time-to-hire reflects it. Months to find a candidate, more months to ramp, and a live risk that the search simply fails are all part of the build path's true cost.
The third number: how often builds stall
The quantity operators most often leave out is the failure rate of the internal build itself. The pattern is consistent across surveys of enterprise AI. A prototype works in a notebook, and then the project stalls on the gap between a demo and something that runs against live data every day without a person babysitting it. We have written about why that last stretch is the expensive one in the 80-to-99% problem, and the same gap is what swallows internal builds. A team that can produce a working proof of concept is not the same team that can keep an agent reliable in production for a year, and the distance between those two is where budgets and timelines disappear. When you price the build path, price it at the probability it actually ships, not the probability it demos.
The decision framework, stated plainly
Set against those three numbers, the framework is literal. Build when the capability is a durable source of advantage that you intend to keep developing, and when you can realistically hire and retain a team to develop it. A logistics firm whose routing model is the core of its margin should own that model. Buy or contract when the goal is a working result on a specific, definable process, on a known timeline, where the value is the running system and not the act of building it: the month-end close, three-way match, a collections workflow, customer onboarding. Most operational AI is the second kind, because most of what an operating business wants automated is a known process that simply costs too many hours.
The condition that makes buying safe is ownership. A bought capability becomes a dependency the moment you cannot run it or change it without the vendor, which is the failure mode behind many sour outsourcing arrangements. So whichever path you take, insist on the same two terms: transfer of ownership of what gets built, and documentation good enough for someone other than the builder to operate and modify it. That is the test we describe in how to tell a vendor that ships from one that demos, and it is what keeps the buy decision from quietly becoming a permanent build decision held by someone else. The operator who never even reached this decision, because no delivery model would take on their actual process, is the one we wrote about in the customer all four delivery models leave behind.
Why buying got cheaper faster than building
The make-or-buy math has shifted, and the reason is on the cost side. Stanford's Human-Centered AI Institute, in its 2025 AI Index report, documents that the inference cost of running a system at the level of GPT-3.5 fell more than 280-fold between November 2022 and October 2024. We traced what that decline did to the economics in what changed in the cost curve. The point for this decision is that the cheaper inference got, the cheaper it became to buy a working result, because the per-task cost of running an agent dropped. It did not, in the same period, make a senior ML engineer cheaper or easier to find. The two inputs moved in opposite directions, which is why the buy path improved faster than the build path, and why a firm structured to deliver running systems can serve many operators on infrastructure that keeps getting cheaper, an economics we set out in why services-as-software firms scale.
A reasonable counter
A reasonable counter is that buying any strategic capability creates lock-in and surrenders the institutional knowledge that comes from building, and that an operator who contracts out AI will never develop the ability to use it. There is real force in this, and it is exactly why the ownership-and-documentation terms are non-negotiable rather than nice-to-have. But the counter assumes the build alternative is available, and for most operators it is not: the talent is priced above what the role can return, the search may fail, and the internal build carries a stall rate that the demo never reveals. The ability worth building is not a standing ML team. It is the discipline of specifying a process precisely, demanding ownership of what gets delivered, and keeping the documentation that lets you operate it after the builder is gone, and that discipline develops whether you build or buy.