Every AI initiative eventually runs into the same fork in the road: do we buy a tool that does this, build something ourselves on top of available models, or decide this is not worth either? Most teams answer with gut feel, a demo they liked, or whatever the loudest vendor in the room was selling. The result is spend that does not match the strategic value of the problem.
This guide is a framework for making that call deliberately — before procurement, before a pilot budget is committed, and before anyone falls in love with a roadmap slide.
Buy, build, or decide not to play.
Buy: adopt an off-the-shelf product.
A vendor owns the capability. You configure it, integrate it, and train people on it. Right when the capability is generic — drafting, summarising, search, meeting notes — and is not a source of competitive differentiation.
Build: assemble on top of models and platforms.
You own the workflow, the data wiring and the prompt or agent logic, while models come from a provider. Right when the workflow is specific to how your business operates and the value comes from that specificity.
Decide not to play — for now.
The most underrated option. Some use cases are not worth pursuing yet: the data is not ready, the process is unstable, or the value is speculative. Parking them explicitly is a decision, not a failure.
Note what is missing from this list: training your own models. For the vast majority of organisations that is not a realistic option — and it is usually raised as a distraction rather than a serious alternative.
What actually decides build vs buy.
Answer these in order. Each one narrows the field.
Is this capability differentiating?
If every competitor could buy the same product tomorrow and nothing about your position changes, buy. If the value comes from your data, your workflow or your relationship with customers, buying hands that advantage to a vendor — and to your competitors.
How stable is the underlying process?
Building AI on top of an inconsistent, undocumented process automates the chaos. If the process is not stable, fix the process first — or buy a tool that forces consistency as a side effect, which can be worth the licence fee on its own.
Who owns the data and the workflow after year one?
Bought tools often require your data to flow through their systems, and lock your process into their roadmap. Built tools keep ownership with you but carry ongoing maintenance. Ask who you want to be dependent on in two years, not just what ships fastest now.
Do you have — or can you hire — the people to maintain it?
Every built system needs an owner: for model changes, prompt updates, evaluation and edge cases. If nobody on your team would own it next quarter, you are not building a capability; you are creating technical debt with an AI label.
Does the provider's vision point where you are going?
Every vendor is building toward a future customer, and it is rarely yours. Read the roadmap, the funding story and how they talk about the next eighteen months. If their direction drifts away from your problem, today's capable tool becomes tomorrow's awkward dependency: you inherit their priorities instead of your own. Shared vision is worth more than a longer feature list, and unlike a feature list it is checkable before anything is signed.
Most real answers are hybrids.
In practice, the buy-vs-build question is rarely binary. The strongest pattern most teams land on is:
- Buy the commodity layer: generic assistants, transcription, summarisation, meeting intelligence — anything where the vendor's scale beats anything you could assemble
- Build the thin, specific layer where your business is different: the workflow logic, the data connections, the judgment encoded in prompts and evaluations
- Rent to learn: pilot a bought tool to understand the problem before committing to build, with a clear exit review
The trap is inverting this: building commodity capabilities in-house because an engineer enjoys it, while buying tools that quietly capture the one thing that makes the business distinctive.
Warning signs worth taking seriously.
These patterns show up again and again in the weeks before a bad build-vs-buy decision:
- The evaluation started from a demo, not from a defined problem and its success measures
- 'Build' really means a proof of concept with no plan for who maintains it after the pilot
- The build case assumes your data is cleaner and more accessible than it is
- The buy case assumes adoption will follow the purchase, with no change plan for the people whose work changes
- The buy case is judged on today's demo, with no view of where the provider's vision and roadmap are heading
- Nobody has written down what would make this initiative a failure worth stopping
If you cannot state, in one sentence, what would make this initiative a failure worth stopping — you are not ready to choose build or buy.
A one-page test before anything is signed.
Before committing to either path, write one page with five answers:
- The specific workflow and who owns it today
- The measure of success — what changes, for whom, by how much
- The dependency picture: data, systems, people and vendor lock-in
- The provider's direction: where their vision is heading, and whether it still fits yours in two years
- The named owner for day one, and the named owner for quarter three
If buying: attach the licence, integration and change-management cost to that page. If building: attach the maintenance plan and the evaluation approach. If you cannot fill in the page, the decision is not ready — and that is a legitimate outcome of the exercise.
Where this fits with everything else.
Build vs buy is not a standalone choice. It sits inside a readiness assessment — you cannot decide sensibly for an unstable process — and it should be visible in your implementation roadmap, so each use case carries its own build, buy or park decision rather than one blanket policy.
Teams that revisit the decision quarterly tend to do best: tools improve, model capabilities shift, and what deserved a build last year may be a cheap purchase today. The point is not to get the answer right once. It is to keep making the decision deliberately.