Buying AI services

Should we build AI ourselves or buy an off-the-shelf tool?

Short answer

Buy when the workflow is standard across your industry — transcription, meeting notes, generic support deflection, code assistance — because a vendor amortises that build across thousands of customers and you will not beat the economics. Build when the process is specific to how your company competes, or when the data lives in systems no vendor integrates with, which is the usual reason mid-market automation has no off-the-shelf answer. The deciding question is not cost: it is whether the unusual part of the problem is your data and workflow or the AI itself, and if it is the AI, buy. Most companies end up doing both, and the expensive mistakes are building a commodity and buying a differentiator.

Last updated August 20, 2026 · Bitfumes AI consultancy · view as Markdown

The question that decides it

Ask what the hard part of this problem actually is. If the hard part is the AI — recognising speech, reading handwriting, generating code — buy it, because that capability is a product with a research budget behind it and no realistic in-house equivalent. If the hard part is that your process is unusual, your data lives in four systems that do not speak to each other, or the rules are yours alone, then the AI is a component and the work is integration, which is exactly what no vendor can sell you.

Signals, and which way they point

Signal	Points to
The workflow looks the same at every company in your industry	Buy
A vendor has a data advantage you cannot replicate	Buy
The process is part of how you compete	Build
The data sits in an internal or legacy system with no public API	Build
You need the output inside an existing tool your team already lives in	Build a thin layer, buy the capability
Regulation forbids the data leaving your infrastructure	Build, on an open-weight model
You are not yet sure the use case is real	Buy or prototype — do not commit to a build to find out

What buying really costs

Per-seat pricing that stops looking cheap at scale, particularly for tools priced per user rather than per transaction.
Integration work you will do anyway — the tool still has to reach your data and your identity provider.
Configuration that is a project in its own right. 'Off the shelf' rarely means 'no implementation'.
Your data crossing a boundary, with the residency, subprocessor and no-training questions that follow.
A roadmap dependency: the feature you need is scheduled by someone whose priorities are not yours.
Switching cost once the workflow is shaped around the tool.

What building really costs

Six to twelve weeks to a first production feature, when the data access is arranged and the scope is one use case.
An evaluation set, and the discipline to keep running it.
An owner after launch. AI systems drift as models and inputs change; an unowned one degrades quietly.
Inference at real volume, which is a running cost rather than a capital one.
The parts that are not the model, which is most of it — permissions, retries, audit trails, the interface people actually use.

The hybrid that usually wins

Buy the commodity capability and build the thin layer where your advantage lives. In practice that means paying a vendor for transcription, extraction or code assistance, and building the part that knows your product catalogue, your approval rules and your customers. The layer is small, it is the only piece a competitor cannot buy, and keeping it in your own repository means the vendor underneath it is replaceable.

Decide in a week, not a quarter

Write the workflow down end to end, including the steps nobody documents.
Mark each step as generic or specific to your company.
Shortlist vendors for the generic run of steps and get real pricing at your volume, not list pricing.
Identify the one specific step where being different is worth something.
If the specific step can be a thin layer over a bought capability, that is your answer, and you have it in a week rather than after a build.

Frequently asked

Is building always more expensive than buying?

Not at volume, and not when per-seat pricing scales with headcount rather than with value. But the comparison people make is usually wrong in the other direction: they compare a vendor's annual fee against a build's development cost and omit the build's ongoing ownership, evaluation and inference costs.

Should a startup ever build its own AI feature?

Yes, when the feature is the product. Buy everything that is not the thing customers pay you for, and be honest about which is which — a great deal of startup engineering time goes into rebuilding capabilities that were available as an API.

What about building on an open-weight model to avoid vendor lock-in?

It removes a dependency and adds an operations burden. It is the right call when residency or regulation requires it, and an expensive way to feel independent when they do not. Keeping the model behind an abstraction gets you most of the portability at none of the cost.

How does the AI Opportunity Assessment handle this?

It maps your workflow, marks which steps are generic and which are yours, and names where an off-the-shelf tool is the better answer — including when that means we recommend you buy something rather than hire us to build it.