Should you build your product on a foundation model API?

The easy half of the decision

Use the API. The capability gap between a frontier model and anything a startup can train is enormous, the cost curve keeps falling, and improvements arrive without you doing anything. Building your own intelligence layer to avoid dependency is a way of spending two years arriving somewhere worse.

The hard half

Every company building on the same APIs has access to the same capability. So the differentiation question is what you have that they don't, and "we prompt it better" is not a durable answer — prompts are copyable in an afternoon.

The categories that hold up:

Proprietary data the model doesn't have and can't get. Your customers' history, your industry's documents, your accumulated corrections.

Workflow ownership — being the system where the work actually happens, so the model output lands in context rather than in a chat window the user has to copy from.

Integrations and permissions — the unglamorous plumbing into systems of record, which is slow to build and slower to displace.

Distribution and trust — particularly in regulated domains where being the approved vendor is worth more than being the cleverest one.

The lesson from the wrapper wave

When foundation model providers shipped features natively, the companies that evaporated were the ones whose entire product was a thin layer over a prompt. The ones that survived had the model as an input to something larger — the workflow, the data, the integrations were theirs, and swapping the model underneath was a Tuesday.

The question to answer before you start

Write down what remains if your provider ships your headline feature next month. If the honest answer is "nothing", you don't have a product yet — you have a demonstration, and the clock started when you launched it.