Most build-versus-buy conversations about AI go wrong in the first five minutes, because both sides are arguing about capability when the actual variable is fit. The vendor demo works. The custom prototype also works. Capability is rarely the discriminator in 2026 — the underlying models are largely commoditised, and both options will sit on top of broadly similar ones.
What differs is everything around the model. Here is the framework we use, in the order the questions actually matter.
Start with the only question that settles most cases
Is this process a source of competitive advantage, or a cost of doing business?
If the honest answer is “cost of doing business,” buy. Expense-report classification, meeting summarisation, résumé parsing, basic ticket routing, transcription — these are solved problems where a dozen vendors compete on price and your differentiated version would be differentiated by nothing. A custom build here spends six figures to produce a slightly worse version of a $40-per-seat product.
If the process is the advantage — the thing your customers pay you for, the judgement your senior people take years to develop, the operational constraint that caps your growth — then a product designed for the median of your industry will, by construction, make you median at the thing you compete on. That is the strongest argument for building, and it is strategic rather than technical.
Most real cases are not at the extremes, which is where the remaining dimensions do the work.
Data gravity
Ask where the data lives and what it would cost to move it.
Off-the-shelf AI products are almost always SaaS, which means your data goes to their environment. For a lot of data, that is completely fine. For some, it is a non-starter: regulated customer financial records, PHI, defence-adjacent engineering data, trade secrets with real monetary value, anything covered by a customer contract that restricts subprocessors.
Pay attention to the cases where it is technically permitted but operationally painful. We worked with a lender whose policy allowed a hosted vendor with an executed DPA — but each new subprocessor triggered a third-party risk review that took eleven weeks and consumed political capital from the same committee they needed for three other initiatives. Technically allowed, practically more expensive than building.
There is also a volume version of this. If the system needs to reason over four million pages of existing documents, the egress, the ingestion time and the per-document vendor pricing stop being a rounding error. Run that arithmetic before you compare licence fees.
Workflow fit, and the integration tax
This is where buy decisions most commonly disappoint, and the failure is predictable.
A product encodes assumptions about how your process works. When those assumptions match, you get value in a week. When they do not, you get a configuration project, then a change-management project, then a quiet reversion to the old process with the product left running to justify the purchase.
Score it honestly on three things:
- Entry point. Does the AI appear inside the tool your people already have open, or does it require a context switch to another tab? Adoption dies in context switches.
- Output shape. Does it emit what the next step of your process actually needs, or something adjacent that a human has to reshape? A summary when the downstream system needs structured fields is not automation, it is a new manual step.
- Exception handling. What happens on the 8% of cases outside the happy path? If the answer is “the user starts over manually,” your effective automation rate is much lower than the brochure implies, because exceptions are where the time goes.
The integration surface is the honest cost of buying. A $60k/year product that needs $200k of integration work and a dedicated owner is not a $60k decision.
Switching cost, in both directions
Buying has lock-in that compounds quietly. Your prompts, your configuration, your evaluation history, your fine-tuned variants and your users’ habits accumulate inside someone else’s product. Three years in, the migration cost is substantial and the vendor knows it — which is also when renewal pricing tends to discover your true willingness to pay.
Building has a different lock-in: you own the maintenance. Models improve, dependencies drift, evaluation sets go stale, and the engineer who built it changes jobs. A custom system without an internal owner degrades. We are explicit with clients about this — if nobody will own it, do not build it, because an unowned system is a liability with a sunk cost attached.
Two questions worth asking before either decision: on buy, can I get my data and my configuration out in a usable format? On build, who is the named owner, and what is their capacity?
The hybrid case, which is usually the right answer
The framing is rarely all-or-nothing, and the best outcomes we see are mixed:
- Buy the commodity layer, build the differentiated layer. Use a hosted model API or an open-weight model for generation. Build the retrieval, the evaluation, the guard-rails and the workflow integration — which is where your advantage actually lives.
- Buy to learn, build to scale. Run a SaaS product for a quarter to find out what your users actually do with it and where it breaks. That is cheap, fast discovery, and it produces a far better specification than any requirements workshop.
- Build the thin custom layer over the bought platform. Sometimes 90% of the value is in the product and the missing 10% is a small integration you can own.
A scoring rubric you can use in a meeting
Score each dimension 1–5, where 5 favours building:
| Dimension | 1 — Buy | 5 — Build |
|---|---|---|
| Strategic value of the process | Pure overhead | Core differentiator |
| Data sensitivity / gravity | Low-risk, small volume | Regulated, on-prem, high volume |
| Workflow specificity | Industry-standard | Unique to your operation |
| Integration surface | One SaaS tool | Several internal systems |
| Internal capacity to own it | None | Dedicated team |
| Required explainability | Low | Auditable, citation-level |
| Expected lifetime | 1–2 years | 5+ years |
Total above roughly 25 and building is likely right. Below 15, buy, and spend the saved budget on adoption. In between, hybrid — and the specific dimension that scored highest tells you which part to build.
The failure mode nobody budgets for
The most expensive outcome is neither building nor buying. It is buying a product, discovering in month four that it fits 60% of the process, then building a shadow custom system around it while still paying the licence — and now maintaining two things, with the integration between them owned by nobody.
That happens when the buy decision is made on capability (the demo worked) rather than fit. Which is why fit, not capability, is the question to lead with.
Working through this decision? Book a consultation — the discovery engagement is deliberately decoupled from any build, and roughly one in five ends with us recommending you buy instead.