Should You Buy or Build the AI Feature Your Customers Are Asking For?

Why do the usual build-versus-buy rules break here?

Traditionally you built what was core and bought what was context. With AI features, the capability itself is available to everyone at the same price, so building the capability confers no advantage.

What differentiates is the surrounding system: the proprietary data you can feed it, the evaluation loop that tells you whether it is getting better, and how tightly it fits your existing workflow.

So the question is not 'can we build this' — you almost certainly can — but 'does building it give us something we cannot rent'.

When is buying clearly right?

When the feature is expected rather than differentiating. Transcription, basic summarisation, standard document extraction and generic chat interfaces are all table stakes; customers notice their absence and never praise their presence.

Also when the vendor absorbs a compliance burden you would otherwise carry, or when your volume is too low to justify an evaluation practice of your own.

Buying is not permanent. Buying to validate demand and building later, once you know exactly what usage looks like, is often the cheapest sequence.

When is building clearly right?

When the feature depends on data only you have, when the output quality is the reason customers pick you, or when latency and cost at your volume make a vendor's per-seat pricing untenable.

Also when the feature must be deeply woven into your own permissions, audit trail or domain model. Vendor integrations tend to sit beside a product rather than inside it, and users feel the seam.

Regulated contexts sometimes force building, though more often they force a specific deployment model rather than a full build.

What does the evaluation loop cost?

This is the line teams forget. A built feature needs a labelled test set, a way to run it on every change, a review process for regressions and someone whose job includes looking at outputs.

Budget for that as ongoing work, not a one-off. In practice it is often a similar order of effort to building the feature in the first place, spread across the following year.

If you cannot commit to that, buy. An unmaintained built feature degrades silently as models, prompts and inputs drift, and you will find out from a customer.

How do you compare the real costs?

For buying: licence or usage fees at projected volume in eighteen months, integration effort, and the switching cost if the vendor changes terms. Vendor pricing in this category has been volatile, so model a significant increase.

For building: engineering time to first release, inference spend, the evaluation harness, and an ongoing quality allocation. Add a contingency; AI features have a long tail of edge-case work.

Compare over eighteen to twenty-four months, not at launch. Buying almost always wins at launch and frequently loses over two years at scale.

Is there a middle path?

Usually, and it is often the right one. Rent the model through an API but own the prompt, the retrieval, the evaluation and the interface. That is technically building, but far cheaper than it sounds because the expensive part is rented.

The other middle path is buying with an exit: insist on data export, avoid deep coupling to vendor-specific formats, and keep your evaluation set in your own repository so you can compare a future build against the incumbent.

Both preserve optionality, which matters more than usual in a category where capabilities and prices move every few months.

Worked example: the same decision made twice

A field-services platform faced two AI feature requests in one planning cycle: automatic call transcription, and a scheduling assistant that proposes technician routes from job notes and history.

For transcription, three vendors offered acceptable accuracy at around 0.006 per minute, with adequate data terms. Estimated volume was 190,000 minutes per year, roughly 1,140. Building would have needed audio pipeline work and an ongoing accuracy practice for a feature no customer would ever choose them for. They bought.

For scheduling, the useful signal was ten years of their own job outcomes — which technicians actually complete which job types on time in which regions. No vendor had that data and no vendor could get it.

They built the scheduling assistant on a rented model, with retrieval over their own history, a labelled test set of 600 past schedules, and a weekly regression run. First version took about nine weeks; the evaluation work has taken roughly a day a week since.

Two years on, transcription is unremarkable and cheap, and the scheduler is the feature named in most competitive wins. Building both, or buying both, would have been worse.

Frequently asked questions

Tools mentioned in this article

More in Business & Money