Build vs buy for AI — a founder's decision framework

TL;DR — Build the AI that is your defensibility; buy the AI that is a commodity capability on the way to it. Most teams get this backwards — building undifferentiated plumbing and renting the thing that should have been their moat.

The build-vs-buy question for AI is usually argued on cost and speed, which is why so many teams answer it wrong. Cost and speed tell you what is cheap this quarter. They do not tell you what you will regret in two years.

The wrong question: what is cheaper to ship?

Framed as a cost decision, buy almost always wins in the short term — a model behind an API is faster and cheaper than training your own. So teams buy everything, ship fast, and discover later that the one capability that was supposed to be their edge is a thin wrapper around the same API every competitor is calling.

The right question: where does your defensibility live?

The decision that matters is which capability is yours — the thing that compounds, that competitors cannot buy off the shelf, that gets better with your data and your users. That, you build. Everything on the way to it, you buy.

Build when it is the moat

If a capability is where your product wins — the model tuned on proprietary data, the workflow only you understand, the feedback loop that improves with scale — building is not a cost, it is the investment. Renting your moat means renting your defensibility to whoever else calls the same endpoint.

Buy when it is commodity plumbing

Transcription, generic embeddings, a foundation model's raw capability, off-the-shelf moderation — these are commodities. Building them is a distraction that burns the team's scarce attention on undifferentiated work. Buy them, wire them in, and spend the saved effort on the moat.

The switching-cost trap

The one place buy quietly turns expensive is switching cost. A bought capability you build a product around becomes hard to leave — pricing changes, the vendor pivots, the model degrades, and you are trapped. Buy commodities behind an abstraction you control, so the vendor is replaceable. Never let a rented capability become load-bearing without a way out.

The uncomfortable pattern

Across engagements the mistake is consistent: teams build the commodity plumbing (because it feels like real engineering) and buy the differentiated capability (because it ships faster) — exactly inverted. The discipline is to be honest about which is which, and to spend your build budget only where it compounds.

This is one of the first calls we make with founders as a technology partner — build-vs-buy set against where the defensibility actually lives, not what is cheapest to ship. It is also why product engineering and strategy belong on one team: the build-vs-buy line is a strategy decision executed in code.

FAQ

How do I decide whether to build or buy an AI capability? Build what is your defensibility — the capability that compounds with your data and users and that competitors cannot buy. Buy the commodity plumbing on the way to it. Decide by moat, not by this quarter's cost.

Isn't buying always cheaper and faster? In the short term, usually. The risk is renting the exact capability meant to be your edge, and the switching cost of building a product around a vendor you later need to leave.

What is the switching-cost trap? Building your product around a bought capability that becomes hard to replace. Buy commodities behind an abstraction you control so the vendor stays swappable.

What do teams most often get wrong? They build undifferentiated plumbing because it feels like real engineering, and buy the differentiated capability because it ships faster — the exact inverse of what compounds.