Mid-sized organisations are running into the buy-or-build question on AI more often, and harder, than they did with previous waves of technology. Two things have changed at once. The off-the-shelf options have multiplied, and most of them now look credible inside a 30-minute demo. At the same time, the internal-build options have gotten genuinely cheaper, because the underlying models are commodity and the integration work is shorter than it used to be.
The old frameworks for buy-vs-build assumed building was slow, expensive, and risky, and buying was the safe default. That asymmetry is no longer reliable. Here are five questions worth working through before a leadership team signs a vendor contract or commits a team to an internal build.
Is the problem actually proprietary
The strongest argument for building is that the problem is specific to your organisation in a way no vendor can serve. Specific data shapes, specific workflows, specific compliance posture. If three competitors in your sector could plausibly use the same software with light configuration, that is a buy signal. If the value comes from the way your team in particular processes a request, that is a build signal, or at least a signal to look harder.
The mistake we see most often is leadership teams convincing themselves their workflow is unique when it is not. The opposite mistake also happens, where a genuinely proprietary process gets squeezed into a vendor template and loses the thing that made it valuable.
What are you actually paying for
AI vendors bundle three different things into one price: access to a model, a data layer (sometimes thin, sometimes substantial), and a workflow on top. Worth being clear which of the three carries the value for you. If you are paying mostly for the model, the underlying model is commoditising fast and you are likely overpaying. If you are paying mostly for the data layer (a curated taxonomy, a benchmark dataset, a pre-trained domain model), that has lasting value. If you are paying for the workflow, ask whether the workflow is something a competent in-house team could replicate in a quarter.
Who owns the data path
Where does your data sit while the system uses it, who has visibility into it, and what happens to it on contract termination. With AI vendors specifically, the model training question matters: is your data being used to improve a shared model that competitors also use. A surprising number of vendor contracts are quiet on this point, and a surprising number of legal teams sign them anyway.
If the data path is sensitive enough that the answer matters, that pushes toward building, or toward a buy option with clear single-tenant guarantees in writing.
What is the realistic cost of switching later
Switching costs on AI tools are higher than they look in the sales cycle. The proprietary data formats, the workflow conventions your team will build around the tool, the integrations into your other systems, the institutional muscle memory. Two years in, the cost of leaving is not the contract value, it is the cost of unwinding everything wrapped around the contract value.
This is not an argument against buying. It is an argument for going in with eyes open about how reversible the decision is, and for negotiating exit terms before the honeymoon period ends.
Can your team actually operate the thing
Both options assume someone inside your organisation can keep the thing running, escalate the right failures, and notice when it has started to drift. Buy options require a vendor relationship owner and someone competent enough to challenge the vendor when needed. Build options require an engineering function with capacity to keep the lights on after the initial team has moved on.
Be honest about which capacity you actually have. A buy decision made because “we cannot build” is the right answer when the operating capacity to maintain a build is genuinely absent. It is the wrong answer when leadership has just not yet had the conversation about staffing it.
Knowing which one you are in
Sometimes buy wins. Sometimes build wins. The point of working through the five questions is to be specific about which case you are in, and to be able to defend the decision to a board or an investor six months later when the costs are real and the early enthusiasm has cooled.
If the answer is not clear after working through them, the answer is often a third option: a small, time-bounded proof of concept that produces enough evidence to make the buy-vs-build call with confidence. Four weeks of focused work tends to settle questions that twelve weeks of meetings do not.