The short answer
How the two options compare
| Buy | Build | |
|---|---|---|
| Time to value | Weeks. Configuration rather than construction. | Months. Discovery, build, evaluation, rollout. |
| Upfront cost | Low. Subscription, often per seat. | Higher, and concentrated at the start. |
| Cost at scale | Rises with seats or usage, indefinitely. | Flattens. You own the asset. |
| Fit | Good for common problems, poor for unusual ones. | Exact, because it was made for your case. |
| Differentiation | None. Competitors can buy the same thing. | Real, where it uses data or process only you have. |
| Maintenance | The vendor’s problem, until they change direction. | Yours, permanently, and it must be budgeted. |
| Data control | Depends entirely on their terms. | Complete. |
| Exit | Migration, and whatever the contract allows. | You already own it. |
When buying is the right answer
Buying wins more often than engineering teams like to admit, and four situations make it clear cut.
- The problem is common. Transcription, document extraction, generic support deflection and meeting summarisation are solved products. Rebuilding them is paying to catch up to a starting line.
- You need it this quarter. No build reaches production in the time a good product takes to configure.
- Nobody internally will own it. Software with no owner decays. If you cannot name the person who maintains this in eighteen months, buy it.
- You are still testing demand. Buy to find out whether people use it, then build once you know they do.
When building is the right answer
- Your data is the advantage. A model trained on transaction history, clinical records or operational telemetry that only you hold produces something no vendor can sell your competitor.
- The workflow is genuinely unusual. If every vendor demo requires you to change how you work, the product is solving a different problem.
- It touches your margin. Anything sitting directly on unit economics is worth owning, because a vendor’s price rise becomes your margin cut.
- Compliance rules out the alternatives. Where data cannot leave your environment, the shortlist of vendors is often empty.
What each option hides
What buying hides
Integration is rarely included in the licence, and it is frequently larger than the licence. Add the cost of connecting the product to your systems, the per seat cost as headcount grows, and the migration cost if the vendor is acquired or changes direction. A product that fits eighty per cent of your process leaves the other twenty per cent as manual work that never goes away.
What building hides
The build is the smaller half. Evaluation, monitoring, retraining and the person who owns it afterwards are ongoing costs that rarely appear in the original business case. A model with nobody maintaining it degrades quietly, and the first sign is usually a customer noticing before you do.
Is there a middle option?
Usually, and it is often the right one. Buy the platform and build the layer that is yours: use a commercial model rather than training your own, but ground it in your own content and wrap it in your own workflow. Most of what people call building AI is really this, and it carries far less of the cost of a true build while keeping the part that differentiates you.
How do I decide between building and buying AI?
Four questions settle it in an afternoon.
- Could a competitor buy the same outcome tomorrow? If yes, buying is fine, because there was no advantage available.
- Does the answer depend on data only you hold? If yes, that is the case for building.
- Who owns this in two years? No name means buy.
- What happens if the vendor doubles the price? If the answer is serious, own it.
Related
- AI consulting: a short discovery that answers this with your own data in front of it.
- What AI development costs: what drives the build side of the comparison.
- AI glossary: plain definitions of the terms this decision turns on.