Build vs Buy for AI: A Decision Tree

The short version

Buy when the capability is generic, the vendor market is mature, and speed matters more than differentiation. Build when the capability touches proprietary data or process logic that is part of how you win. Most organisations should buy the platform and build the last mile — the prompts, the workflows and the integrations that encode their own way of working.

The decision tree

1. Is this capability part of your competitive differentiation? If no → buy. Transcription, translation, document OCR, generic chat interfaces are commodities.
2. Does it depend on proprietary data or process rules a vendor cannot see? If yes → build the logic layer, buy the model.
3. Is there a credible vendor with reference customers your size? If no → build, but scope it tightly.
4. Can you staff it for three years, not three months? If no → buy. Unmaintained internal AI decays faster than conventional software because models, prices and APIs move.
5. Do regulatory or data-residency constraints exclude the vendor set? If yes → build or self-host.
6. Is the time-to-value difference greater than one quarter? If yes → buy first, revisit at renewal.

The three-layer model

Treat any AI capability as three layers and decide separately for each:

• Model layer (foundation models, embeddings, speech). Buy. Nobody outside a handful of labs should be training foundation models.
• Platform layer (orchestration, retrieval, evaluation, observability). Buy or adopt open source. Building this is where budgets disappear.
• Application layer (your prompts, your data, your workflow, your guardrails). Build. This is the only layer where you can create a durable advantage.

Most "we built our own AI" projects that failed were attempts to rebuild the platform layer. Most that succeeded were disciplined application-layer builds on bought infrastructure.

Costs people forget on each side

Buying

Per-seat pricing that scales badly, data egress and export limits, vendor lock-in through proprietary prompt formats, integration work you still have to do, and renewal leverage that shifts once the tool is embedded. Ask for export tooling and a data portability clause before signing.

Building

Evaluation harnesses, prompt regression testing, model version migrations, on-call, security review, and the opportunity cost of senior engineers. A realistic internal build carries about 20% of build cost per year in maintenance, plus a full model migration roughly every 12–18 months.

A worked example

A mid-market insurer wants AI-assisted claims triage. Decomposed:

• Document extraction from PDFs and photos → buy (mature vendors, commodity accuracy).
• Policy interpretation and fraud signals encoded from 15 years of claims history → build (this is the differentiator and the data is proprietary).
• Case management UI and audit trail → buy if the existing claims system can be extended; build only the review screen.

Result: two bought components, one focused internal build of roughly 400 engineering days instead of a 2,000-day platform programme, with the differentiating logic under the insurer's control.

Hybrid patterns that work

• Buy now, build later. Ship with a vendor to prove demand; build once volume makes unit economics favour you. Set the trigger numerically at the start.
• Build the abstraction. Keep a thin internal interface over the model provider so switching costs stay low. Two providers configured, one in use.
• Buy the platform, own the evaluation. Even on a bought stack, keep your own test set and quality scoring. It is your only leverage at renewal and your only defence against silent vendor regressions.

Red flags in vendor selection

No exportable logs. No documented evaluation methodology. Pricing that only makes sense at low volume. Refusal to state which models sit underneath. No roadmap for model deprecation. Reference customers who are all pilots.

Red flags in internal builds

No named owner after launch. No evaluation set. Success measured by demo quality. A single engineer who understands the prompts. Scope that includes rebuilding retrieval, orchestration and observability from scratch.

How to decide in a week

Day one: write the capability down as a user outcome. Day two: split it into the three layers. Day three: shortlist two vendors and get pricing at your real volume. Day four: estimate the internal build at the application layer only. Day five: compare on three-year TCO, time-to-value and strategic control, and record the decision with a review date. Revisiting on a schedule matters more than being right first time.