Build, buy, or wrap: how to add AI to your product without overpaying

A board meeting ends with "we need to add AI," and the question lands on your desk as if it has one answer. It has three. You can buy a finished product and plug it in, build a custom feature yourself, or wrap a third-party platform inside your own integration so you keep control of the data and the experience. Each is right in different situations, and the expensive mistakes come from treating the decision as build-or-nothing. Here is how to actually choose.

Buy: fastest, until it is not

Buying an off-the-shelf AI product (a support bot, a writing assistant, a vendor's "AI" add-on) is the fastest path to something live. For a generic need at low volume, it is usually the right call. You are not in the LLM business; you are in your business, and a tool that already works beats one you have to build.

The limits show up later. You answer from the data the vendor lets you connect, in the experience the vendor designed, at the price the vendor sets, and your usage trains a roadmap you do not control. When the AI feature is the thing customers come for, renting it from someone else stops making sense.

Build: control, at a real price

Building a custom feature gives you the opposite trade. You own the data, the experience, the cost curve, and the observability. For anything that is core to your product, that ownership is the point.

But understand what you are actually buying. The model is the cheap part. As we argue in RAG vs fine-tuning, the model is rarely the bottleneck; the work that determines whether the feature is reliable is everything around it. On a real build, the larger share of the effort goes to the data: cleaning it, structuring it, getting retrieval to surface the right passage instead of a plausible wrong one. Industry write-ups commonly put data preparation at roughly a third to a half of the cost of an AI feature, and that matches what we see. Add access control so the model never returns a record a user should not see, fallbacks for when it is unsure, and an evaluation suite so "it feels better" becomes a number, and you have the real scope. We broke down those layers in anatomy of a production AI feature.

Wrap: the underrated third option

Between buy and build sits the option most teams skip: wrap a platform. You use a provider's model and infrastructure, but inside your own thin layer that owns the data access, the prompts, the guardrails, and the user experience. You get the platform's capability without hard-coding your product to it, and you can swap the provider underneath when price or quality shifts.

For most teams adding their first serious AI feature, this is the pragmatic middle: faster than building the infrastructure from scratch, far more control than buying a finished box. The cost is a real integration layer, but it is the layer you would want to own anyway.

Where the cost actually hides

Whatever you choose, the bill is rarely where founders expect. The model API is a small, shrinking line item. The cost lives in:

• Data preparation. Cleaning, structuring, and indexing your content. The single biggest line on most builds.
• Access control. Making sure retrieval respects who is allowed to see what. Skipped, this is a data leak.
• Fallbacks and evals. Handling the "I am not sure" case, and measuring quality so a regression is caught before a customer finds it.
• Run cost. Without caps and caching, token spend and retries quietly grow. You cannot optimise what you do not meter.

A team that budgets only for the model API and ships will pay for the rest later, usually under pressure.

The decision

The honest version of this decision is not religious. Buy the parts that are generic, wrap the parts where you want control without the full build, and build the part that is genuinely yours. If you are weighing where AI fits in your product and what it will really cost to run, book a call. We will tell you which of the three you actually need, including when the cheapest good answer is to buy something and move on.