Should we build or buy an AI solution?

Start from differentiation, not cost

The cost comparison is usually the least useful frame, because the two options are rarely doing the same job. The better question: does this system encode something specific to how I operate?

If the answer is no, buy. Nobody gains advantage from a bespoke meeting transcription tool.

If the answer is yes, meaning the system depends on your document corpus, your approval workflow, your domain rules or your data model, building becomes defensible, because vendor products necessarily generalise and generalising away your specifics is exactly what breaks them.

Buy when

• The use case is horizontal and well served: transcription, coding assistance, general enterprise search, translation.
• Your requirements are close to the vendor’s defaults. Every deviation is configuration debt.
• Time to value matters more than fit.
• You have no engineering capacity to maintain a system after launch. This is the most commonly ignored criterion. An unmaintained internal AI system degrades quickly as its data drifts.

Build when

• The system’s value comes from proprietary data or a proprietary process.
• Data residency, sovereignty or access control requirements that vendors cannot meet. Common in European regulated sectors and public bodies.
• The domain judgement required cannot be encoded by someone outside your field.
• Per-seat vendor pricing becomes irrational at your scale.
• The capability is close enough to your core business that outsourcing it means outsourcing your advantage.

The hybrid outcome

Most organisations that do this well end up buying horizontal tooling for productivity, buying platform components rather than writing them (gateways, observability, vector stores), and building the two or three systems that touch their differentiating data.

That last category is small on purpose. Organisations that try to build everything ship nothing; organisations that buy everything end up with a generic capability set and a lot of vendors.

The step that resolves most arguments

Before deciding, spend a week testing feasibility against real data. Can the information needed actually be retrieved from these documents? Is the source data clean enough? Does the accuracy bar look reachable?

In my experience, most build-versus-buy disagreements are not really about build versus buy. They are unspoken disagreements about whether the use case is viable at all, and a feasibility probe settles that in days for a fraction of what either path costs.

If you buy, ask these

Where does inference run and can it be restricted to a region? Is my data used for training, and is that contractual or a setting? Can I export my data and configuration if I leave? What evaluation evidence supports your accuracy claims? How do you handle access control against my existing permission model?

Vendors who answer these precisely are worth talking to. Vendors who deflect are telling you something.