The build vs buy AI features debate almost always collapses into the wrong question. Someone asks "should we train our own model," the room argues for an hour, and the real decision goes untouched. For a post-product-market-fit SaaS, training a model is the one thing you almost certainly should not build. So the binary is broken before you start.

The better frame is layers. An AI feature is not one thing you buy or build. It is a stack: a model, the infrastructure under it, your data, the UX, and the workflow logic that makes the feature feel native to your product. Some of those layers are commodities you rent. One or two of them are the reason a customer keeps paying. The job is to own the layers that differentiate and rent the rest, the same way you already add AI to your SaaS without betting the company on a single vendor or model.

This piece gives you the decision frame, the cost math, and the one rule that keeps a build-vs-buy call from turning into a liability you cannot reverse.

Should you build or buy AI features? Decide by layer, not by feature

The answer to "should you build or buy AI features" is: both, and you decide layer by layer. Buy the commodity layers, build the ones that carry your differentiation, and refuse any setup that ties a core flow to a single vendor.

This matches what actually happens in practice. Companies buy third-party AI where it exists and build in-house where off-the-shelf isn't ready or specific enough, according to Bain's enterprise AI survey, which also found only about 35% of companies have a clearly defined vision for how AI creates business value. The build-vs-buy call is not one verdict. It is a set of smaller calls, most of which point to "buy."

Here is the stack, layer by layer, with the default verdict:

Read the table top to bottom and the pattern is obvious. The layers you should rent are the ones the "build our own AI" debate fixates on. The layers you should own are the ones it ignores.

The commodity layers: when is buying an AI feature cheaper?

Buying is cheaper whenever the layer is a commodity, which is almost always the model and the infrastructure. The model is the most expensive thing to build and the least valuable thing to own.

The cost math is lopsided. In a16z's read of enterprise AI, one executive estimated that "LLMs are probably a quarter of the cost of building use cases", with development and integration eating the majority of the budget. So even if you could build the model for free, you would still spend most of the money on the layers around it. The model is not where the cost lives, and it is not where the value lives either.

The scale of the commodity confirms it. Menlo Ventures found that the LLM layer commands $3.5 billion of enterprise investment, a shared pool that every product rents from. You do not need to own a slice of that pool. You need an API key and a credit card. The cheap, fast, reliable move is to rent it and spend your engineering on the layers a vendor cannot give you. This is also where most SaaS AI tools earn their keep: as rented commodity parts you wrap, not core flows you depend on.

A simple way to make the call per layer:

Buy when:   commodity AND low switching cost AND not a core flow
Build when: differentiating OR core-flow-critical OR encodes proprietary data
 
Rough cost:
  build  = model_cost (~25%) + integration + UX + reliability + maintenance
  buy    = vendor_fee + integration + switching_risk
 
If a layer is commodity, build rarely wins on cost.
If a layer is differentiating, buy rarely wins on value.