Build, buy or wrap?

Sooner or later every product team with an AI idea has the same meeting. One person wants to buy a tool that already does it. Another wants to build it in-house. A third suggests using a model through an API and building the product around it. All three are sometimes right.

Having worked on AI proposals with consulting, engineering and sales teams across Azure, AWS and GCP, I have seen this decision made well and badly. The bad versions usually treat it as a technology choice. It is a choice about where your product's advantage comes from.

The three options

"Wrap" is sometimes used dismissively, as in "just a wrapper". In enterprise products it is where most of the value sits. The model is a component. The workflow, the data access, the guardrails and the review process are the product.

When to buy

Buy when the problem is the same for every company and solving it does not set you apart. Meeting transcription, generic code assistance and document summarisation are examples. A vendor serving thousands of customers will improve faster than your team can, and your engineers are free for work only you can do.

Check three things before signing.

• Data. Where does your data go, and can the vendor use it?
• Fit. Does it work inside the tools your people already use?
• Exit. If you leave in two years, what do you take with you?

When to wrap

Wrap when the general capability exists in a model, and the hard part is applying it to your domain. This is the common case for enterprise AI. The model can already read, reason and draft. What it lacks is your data, your rules and your workflow.

The work in a wrap project is mostly not about the model.

1. Getting the right information to the model at the right moment.
2. Defining what a good output is and testing for it.
3. Designing what happens when the output is wrong.
4. Fitting the result into a workflow people already follow.

That list is the product. A competitor can call the same model tomorrow. They cannot copy your understanding of the domain or the test set you built from real cases.

When to build

Build your own model when three things are true together: the task is central to your business, general models do it poorly, and you have data others do not. That combination is rarer than it sounds. Building also commits you to ongoing cost: training, evaluation, hosting and a team to maintain it.

A useful test is to try the wrap approach first. If a general model with good context gets you most of the way, the case for building is weak. If it clearly fails after a serious attempt, you have learned exactly what a custom model would need to do.

A decision table

Most teams I have worked with end up with a mix: buy the commodity tools, wrap for the product features that matter, and build almost nothing. That is a sensible outcome, not a lack of ambition.

Keep the option to switch

Whatever you choose, models and vendors will change faster than your product does. Two habits keep you flexible.

• Own your evaluation set. If you can test any model against your own cases, switching becomes a measured decision instead of a leap.
• Keep prompts, data access and business rules in your code. If they live inside a vendor's product, you cannot move them.

Questions to ask your team this week

• For each AI initiative, are we buying, wrapping or building, and did we choose deliberately?
• Where does our advantage actually come from?
• Could we swap the underlying model in a month if we had to?
• What would we lose if our main AI vendor changed its terms?

The decision is easier once you stop asking which technology is best and start asking which parts of the product need to be yours.