Build, buy or partner:
what fits your situation?

When does an organisation choose build, buy or partner for AI?

The choice between build, buy or partner for AI depends on four questions: is the application distinctive, what does it cost in year five, who needs to be able to steer the outcome, and how does the exit work. Building yourself only fits what sets an organisation apart in the market, buying fits everything that's a commodity, and a partner fits applications that need steering on the outcome without owning the technology. The setup that holds up most often is a mix: buy the building blocks, build the layer that holds your own knowledge, and bring in a partner for the implementation.

Does building it yourself stay cheap after year one, when choosing between build, buy or partner?

The conclusion often reverses once the maintenance is calculated over five years and compared with a licence: for build, buy or partner, building is cheap in year one.

When in doubt between build, buy or partner, is buying the cheapest way to learn what's needed?

Almost always: when in doubt between build, buy or partner, buying is almost always the cheapest way to learn what's actually needed. Building later is still possible, with a sharper specification.

Source: article by Dave Willemstein. Updated: October 2026.

Why this choice weighs heavier with AI

With classic software, build-or-buy was mainly a cost question. With AI, three extra factors make the trade-off structurally different.

First, the underlying technology changes faster than your depreciation period. A model you fine-tune yourself today can be overtaken within eighteen months by a generic model that does it better out of the box, and more cheaply. Second, maintenance is fundamentally different: models quietly degrade as reality shifts, which calls for permanent monitoring rather than occasional patching. Third, the value often doesn't sit in the model but in your data and your working process, and you can't buy either of those anyway.

The four questions that decide the choice

Question 1: Is this distinctive, or is it a commodity?

The only good reason to build it yourself is that it sets you apart in the market. Not that it's fun, not that your team can do it, and not that it looks cheaper.

A hard test: can your main competitor buy the same result from a supplier tomorrow? If the answer is yes, it's a commodity, however technically interesting it is. Document extraction, speech recognition, summarising, standard classification: all commodities. The way you combine those building blocks with your own data and processes: that's where the distinction can lie.

In practice, at most ten to twenty per cent of what organisations want to build is genuinely distinctive. The rest gets built because it can be.

Question 2: What does it cost in year five?

Building is cheap in year one. You have a team, it builds something, it works. The costs that come after are rarely counted in:

• Model monitoring and retraining as the data shifts
• Keeping up with the underlying models and API versions
• Security, logging and audit trail
• Documentation and knowledge transfer when people leave
• The opportunity cost of engineers maintaining this instead of building something new

A rule of thumb from practice: the annual maintenance of a self-built AI application runs between 20% and 40% of the original build cost. Run that through for five years and compare it to a licence. The conclusion often reverses.

Question 3: Who needs to be able to steer the outcome?

This is the question that justifies partnering. There are applications where you don't need to own the technology, but you do need influence over how the outcome comes about. Think of risk models, pricing, or anything that communicates towards customers on behalf of your brand.

A standard product rarely gives you that influence. Building it yourself gives you full influence but also the full burden. A partnership arrangement (where a supplier builds and manages, but you set the rules, thresholds and evaluation criteria) sits in between. It works if you arrange it well contractually, and it goes wrong if you run it on trust.

Question 4: How do you get out of it again?

The exit question belongs in the design, not in the renewal discussion three years from now. For each of the three options, exit looks different:

• Build: exit means finding someone who understands your codebase. The risk sits in key-person dependency and missing documentation.
• Buy: exit means getting your data and your configured logic out. Establish the format and the timeframe before signing.
• Partner: exit means handover of both the build and the knowledge. Include a handover clause with a concrete deliverable, not an intention.

The hybrid form that works most often

In most projects I guide, the answer isn't one of the three in pure form. The setup that holds up most often:

• Buy the building blocks. Models, infrastructure, standard components. This is where suppliers have economies of scale you'll never match.
• Build the layer that holds your knowledge. The rules, the prompts, the evaluation sets, the link to your processes. This is small in scope and large in value.
• Partner for implementation. But keep ownership of the evaluation criteria yourself.

Concretely: an organisation automating document processing buys the language model and the platform, builds its own field-extraction rules and a test set of two hundred assessed files, and has the integration done by a partner. The test set is the most valuable part and costs the least money.

Three situations where the choice is clear

Build if it touches directly on why customers choose you, you have exclusive access to the data, and you have a team that can still maintain this in five years.

Buy if there are three or more serious suppliers, the functionality is stable, and your main concern is time to value.

Partner if the technology is mature but the application is sensitive, and you want to steer the outcome but not the codebase.

Still unsure? Then buying is almost always the cheapest way to learn what you actually need. You can still build later, with a sharper specification and without losing a year.