Every AI build-versus-buy discussion eventually splits along the same lines. Engineering wants to build because the vendor's product does not quite fit. Finance wants to buy because the licence is a known number. Both are arguing from position rather than evidence, and the decision usually goes to whoever is more senior in the room.
Three questions resolve it more honestly.
One: is this closer to your margin or your overhead?
If the capability is part of what customers pay you for - the thing your product does better than the alternatives - building it keeps the advantage inside the company. If it is a supporting function that every company in your sector needs and none of them competes on, buying it is almost always right.
The test is simple: would a customer notice, and care, if this worked meaningfully better than the market standard? A document-classification step buried in an internal workflow does not pass. The core prediction your product sells does.
Teams get this wrong in a predictable direction. Interesting problems attract engineering attention regardless of whether they are commercially load-bearing, and "we could build that" quietly becomes "we should."
Two: what does the total cost look like in year three?
Buying has an obvious price and a hidden ceiling. Building has an obvious cost and a hidden tail.
| Buy | Build | |
|---|---|---|
| Year one | Licence, integration, some workflow redesign | Team time, infrastructure, evaluation setup |
| Year two–three | Licence growth with usage or seats, limited leverage at renewal | Maintenance, model updates, staff turnover, on-call |
| Exit cost | Migration off a proprietary data model | Nothing to migrate from, but nothing to hand back either |
| Risk carried | Vendor roadmap, pricing changes, viability | Key-person dependency, quality drift, opportunity cost |
The comparison that misleads is year one against year one. Building looks cheap because the ongoing cost of ownership sits in salaries that are already being paid. Buying looks expensive because the invoice is visible.
Run the comparison over three years, include the cost of the people who will maintain what you build, and include what those people would otherwise have shipped. That last figure is usually the largest and the least discussed.
Three: how fast is the underlying capability moving?
This is the question that has changed most in recent years, and it cuts both ways.
Where the underlying models are improving quickly, anything you build on top of them has a short shelf life - but so does the vendor's product, and vendors sometimes absorb improvements faster than an internal team can. Where the capability has stabilised, building becomes more defensible because what you build stays valid long enough to repay itself.
The practical version: if you expect the general-purpose tools to do this adequately within a year, do not spend six months building it. Bridge with something you buy, keep the data and the workflow under your control, and revisit.
What the answers usually add up to
Most organisations end up in the same place: buy the platform, build the thin layer that is actually yours. The infrastructure - serving, monitoring, retrieval plumbing, the standard components - is bought or adopted from open source. What gets built in-house is the evaluation set, the domain logic, and the data pipeline, because those encode the knowledge that makes your version better than a competitor's.
That split also fails gracefully. If the vendor disappoints, the layer that carries your advantage is still yours. If your build stalls, the platform underneath still runs.
Two things worth writing down
Whichever way the decision goes, record two things while the reasoning is fresh.
The first is the assumption the decision rests on - the volume, the price, the capability expectation. When that assumption breaks, the decision should be revisited, and having it written down turns an argument into a review.
The second is the exit. If you bought, what would it take to leave, and do you still hold your own data in a form you could take with you? If you built, what would you buy instead, and what would that migration cost?
Neither takes more than a page. Both save the next budget cycle from relitigating a decision nobody can remember the reasoning for.