Build, buy or partner: an AI decision framework with real costs

Take a mid-sized insurer — a composite of several conversations I have had in the past two years — with three proposals on the table for a document assistant in its claims teams. A SaaS copilot at a monthly price per seat. A system integrator’s platform, fixed-price build plus support contract. And an internal plan: two engineers, an open-weight model on EU-hosted GPUs, retrieval over the claims archive. Each proposal is the cheapest one — on its own slide, over its own horizon, with its own definition of done.

The question underneath is not which option costs least. It is what the insurer would be buying. This guide is the method I use for that question: three gates before any price list, a three-year cost model that includes leaving, and explicit scores for lock-in and sovereignty. It ends where most real decisions end — with a hybrid — but with the reasons written down.

Every option buys three things at once

Whatever you choose, you acquire three things. A capability: the thing does the work. A dependency: someone or something you now rely on — a vendor, a model provider, a partner, or your own team’s continued existence. And an option: whatever the choice makes cheap or expensive to do next.

Vendor decks price the capability. The cost is mostly in the dependency — contracts, price changes, integration, the people who have to understand the thing. The strategy sits in the option: whether next year’s use case is a configuration change or a new procurement.

Simon Wardley’s evolution axis — genesis, custom-built, product, commodity — is the cleanest tool I know for a first cut. Model access has moved from genesis to commodity in about three years. The Stanford AI Index reports that the inference price for a fixed level of capability fell more than 280-fold between late 2022 and late 2024, and that open-weight models trail closed ones by a low single-digit percentage on common benchmarks. Buying a commodity is right; building a commodity is vanity. The mistake is to treat the layer over your own data — retrieval, workflow integration, evaluation, domain rules — as a commodity too. It is custom-built by definition, because nobody else has your data.

Three gates before any price list

Gate one: differentiation. Geoffrey Moore’s distinction between core and context still does the work here. Core is what customers pay a premium for and competitors cannot easily copy; context is everything that must work and nobody notices. A claims assistant that answers policy questions faster is context for almost every insurer. One that settles simple claims with a documented, auditable rationale could be core. The test is blunt: would a customer, an auditor or a competitor notice if this were markedly better than what the market sells? If not, buy it, and spend your engineers on something that would be noticed.

Gate two: data and sovereignty. If the use case touches confidential or regulated data, the option has to satisfy the sovereignty level that data class requires on all four dimensions — location, jurisdiction, control and portability — which I have laid out in a separate article. A SaaS product operated from outside the EU fails the jurisdiction test unless an EU entity operates it with EU-held keys; several vendors now offer exactly that, at a price and with caveats in the sub-processor list. Read the sub-processor list, not the marketing page. If no sensitive data is involved, buying or partnering with plain EU hosting is fine.

Gate three: operating capability. Building is not the expensive part; running is. On-call. Model updates that change behaviour. Evaluation runs before every prompt change, because a prompt change is a production change — DORA supervisors see it that way, and so should you. Security patches. The person who leaves. If you cannot name the two people who will run the system in month eighteen, you are not building; you are partnering with a date, and the contract should say so.

Three times yes is the case for building — on open standards, with the exit designed before the first commit. Everything else has a default that is cheaper and more honest than a build nobody can operate.

Total cost over three years, not price per seat

The price per seat is the only number that is easy to compare, which is why it dominates the discussion and why it is the wrong number. The cost of an AI capability has at least seven components, and the options distribute them very differently:

Component	Build	Buy	Partner
Licence or usage	Model hosting or API tokens	Per seat or per token, rising with adoption	Included in the build, then a support fee
Integration	Your engineers	Never once; again at every upgrade	Change requests
Data preparation	You — and it is most of the work	Still you	Partly the partner, with your data owners
Evaluation and QA	You	You; vendors cannot	Shared, then you
Operations	You, from day one	The vendor, within its SLA	The partner, then you
Adoption and change	You	You	You
Exit	Low, if built on standards	Export, re-integrate, retrain	Handover, if the contract says so

Three things the chart shows that a price list hides. Buying is front-loaded in nothing and grows with success: seats increase because adoption works, and list prices rise because they can. Building is front-loaded in people and flattens once the system runs. Partnering sits in between, and its second-year cost is mostly change requests — the things you discover you needed once real users arrive. In this model the SaaS option passes the build on cumulative cost around month twenty-eight. Your numbers will differ; the shape rarely does.

The chart stops at month thirty-six because contracts do. The cost of leaving is not on it, and it is the number that decides the long run: exporting data in a usable format, re-integrating, retraining people, re-embedding a corpus. In the model it is roughly 150k for the SaaS option, 80k for the partner build and 25k for the in-house build. Ask for it in the tender. A vendor who cannot quote an exit is quoting a permanent relationship.

Lock-in has five forms, and each has a price

Lock-in is usually discussed as a feeling. It is better handled as five separate costs you can estimate before signing.

1. Data lock-in. Proprietary formats, no bulk export, embeddings you cannot take with you. Price: export, transform, re-embed. Test it during the trial: ask for a full export and try to load it somewhere else.
2. Model-behaviour lock-in. Prompts, examples and guardrails tuned to one model’s quirks. Switching means re-tuning and re-evaluating. Price: an evaluation run and a few weeks of tuning — small if the evaluation set exists, open-ended if it does not. Keep the model behind an interface you could swap.
3. Workflow lock-in. The tool’s interface has become the process; people’s habits live in it. Price: retraining and a productivity dip. Real, and usually underestimated by the people who never use the tool.
4. Contractual lock-in. Minimum terms, automatic renewal, price escalators, deletion terms. Since September 2025 the EU Data Act obliges providers of data processing services to support switching and phases out switching charges by January 2027; check whether your service falls within its scope and use it in negotiation.
5. Skills lock-in. Your team knows the vendor’s platform, not the domain. The price appears on the day you want to leave and nobody can describe what the system actually does.

For financial entities none of this is optional: DORA requires documented and tested exit strategies for critical ICT services, and a model provider or AI platform is one. For everyone else it is simply the difference between a decision and a permanent condition.

Sovereignty is a score, not a checkbox

Score each option on the four dimensions, per data class, from zero to four. A SaaS product operated from outside the EU typically scores well on location, poorly on jurisdiction and control — the provider holds the keys — and poorly on portability. The same product operated by an EU entity with customer-managed keys moves up on jurisdiction and control; portability depends on the export you tested under lock-in. A partner build scores whatever the partner’s stack scores, so insist on open standards at every boundary. An in-house build on EU infrastructure scores highest on control and jurisdiction, and its portability is a matter of your own discipline: infrastructure as code, portable formats, a restore tested on a second provider.

Sovereignty is a spectrum. Decide per data class which level you need, score the options against it, and write the reasoning down. A public body will weight it heavily; a start-up handling no personal data may weight it lightly. Both are right, for their situation.

Put it on one scorecard

The scorecard does not decide. It makes the discussion explicit: the argument is in the weights, and the weights come from the strategy. In the insurer example the build and the partner options come out close, and the SaaS copilot loses on exit cost and jurisdiction despite winning clearly on time to value. That is a typical outcome for regulated data, not a rigged one. Change the data class to marketing copy and the copilot wins.

The normal answer is a hybrid

Real decisions rarely land on one column. The pattern that holds up:

• Buy the commodity layer. Model access — an EU-hosted inference endpoint or open-weight models on your own GPUs — behind an interface you could swap in a fortnight.
• Build the differentiating layer. Retrieval over your data, the workflow integration, the evaluation harness, the domain rules. This is the part context engineering is about, and it is yours whether you like it or not.
• Partner where you lack a capability temporarily, with a transfer clause — code, documentation, runbooks, a handover sprint — and a date on which your people take over.

Three anti-patterns account for most of the expensive mistakes I see: building everything because the engineering team is excited; buying the platform and then customising sixty percent of it; and partnering without an end date, which is buying with extra steps.

What this means for your next decision

In the version of the insurer story that ends well, the hybrid wins: an open-weight model on EU GPUs, a partner build with a nine-month transfer plan, and the retrieval layer over the claims archive owned in-house from the first day. When the model is swapped a year later, it is a two-week job, because the evaluation set exists. When the sales department’s separately bought copilot raises its price and its export turns out not to work, the finance director knows exactly which step that decision skipped.

None of that is luck. It is the third thing every option buys — the option itself — taken seriously at the moment it was cheapest to take seriously: before signing.