Build vs buy AI comes down to one question. Is this a capability every company in your sector needs, or something that makes you different? If it is common, buy an off-the-shelf product. If it is yours, and your own data makes it better, build. Most B2B companies land in the middle: they buy access to a model and build the integration around it. And the honest answer is buy more often than most buyers expect.
This framework covers the three options and what each costs over three years. It also covers the factors that decide between them: data, differentiation, compliance and EU data residency, and what it costs to switch later.
The build or buy AI decision matrix
Read across each row and see which column describes your situation. If most of your answers sit in one column, that is your default. Where they split, the sections below explain which rows should win.
| Factor | Buy a product | Buy the model, build the integration | Full custom build |
|---|---|---|---|
| The problem | Common across companies: transcription, meeting notes, writing help, support deflection | A common capability that must work on your data and inside your systems | Specific to you, and no product does it |
| Your data | Generic knowledge is enough | Your documents and records make the answers better | Your proprietary data is the advantage |
| Differentiation | Parity. Competitors can buy the same thing | Partial. The integration and workflow are yours | High. The AI is part of what customers pay you for |
| Users and volume | Few seats, or usage that stays flat | Many users or high volume, where per-seat pricing hurts | Very high volume, or unit costs that need tight control |
| Compliance and residency | The vendor proves EU processing, signs a DPA and does not train on your data | You choose the EU region endpoint, the logs and the retention | Full control, including open weights models on your own hardware |
| Time to first use | Days to weeks | Weeks to a few months | Months |
| Typical cost | A subscription, often per seat per month | €10,000 to €50,000 for features and integrations, €25,000 to €80,000 for most agents, plus model usage | €50,000 to €100,000 for a custom app, €100,000 and up on private infrastructure |
| Switching cost | Whatever the export leaves behind, plus retraining staff | Low, if prompts and evals are yours and the model is swappable | Low for the model, high if one person holds all the knowledge |
When an off-the-shelf AI product wins
Buy when the problem is common and the product's workflow already matches yours. Transcription, meeting summaries, writing assistance, code completion and generic support deflection are mature product categories. The vendor spreads its engineering cost across many customers. You will not build a better version for the price of a few hundred euros a month.
Buying also wins while you are still learning what you need. A few months on a good tool shows you how people actually use the capability, and which parts they ignore. That is cheap discovery, as long as you can take your data with you when you leave.
And it wins on small budgets. Below about €10,000, the discovery, eval and deployment work of a custom build costs more than the feature is worth. At that size we point people to an existing tool rather than take the project.
Buy when most of these are true:
- The task looks the same in your company as in most others.
- The product connects to the systems you already use through a native integration.
- Seat count and volume will stay modest for the next three years.
- The vendor processes data in the EU, signs a DPA and does not train on your data.
- You can export your data, configuration and history in a format another system can read.
When a custom build wins
Build when the AI touches what makes you different. If your product or your service quality depends on it, renting it gives you parity at best. The same vendor sells it to your competitors.
The other strong signals are practical. The workflow spans your own systems, such as a CRM, an ERP and an internal database, and writes back to them. Per-seat pricing grows with headcount, while the build price barely changes between 20 users and 200. Or the use case is regulated, and you need control over logging, human oversight and where processing happens.
A full custom build still rarely means training a model from scratch. It means a product of your own, sometimes on open weights models running on hardware you control. With us, a custom AI web or mobile app usually runs €50,000 to €100,000. Private AI infrastructure starts at €100,000. Fine-tuning comes in only after prompting and retrieval have been exhausted, because it adds a maintenance cost most teams underestimate.
The middle path: buy the model, build the integration
For most B2B companies, the right answer is neither pure option. You buy access to a model from Anthropic, OpenAI or Google, ideally through an EU region endpoint. You build everything that makes it useful in your business: retrieval over your documents, connections to your systems, permissions, evals and the interface your people use.
Most of what we build sits here, and the economics explain why. Almost no company should train its own foundation model. But the layer that holds your data and your workflow is exactly what a product vendor cannot fit to you. The middle path puts your money into that layer and nowhere else.
The ranges are smaller too. One AI feature inside existing software runs €10,000 to €25,000. A multi-feature LLM integration runs €25,000 to €50,000. Most agents, which take actions inside your systems rather than just answer questions, land between €25,000 and €80,000.
The middle path also keeps switching cost low. If the prompts, eval set and retrieval pipeline are yours, the model becomes a component. When a better or cheaper model ships, you run your evals against it and switch, often within days.
Total cost of ownership over three years
The most common mistake in this decision is comparing a monthly subscription with a one-off build price. Put both on a three year basis. Buying costs licenses or usage, setup, internal admin time and the cost of leaving. Building costs the build itself, model usage and hosting, and maintenance.
Maintenance is the line people forget. Plan for 15 to 25 percent of the build cost per year for monitoring, eval updates and model changes. Providers retire model versions, and the system has to be tested against their replacements.
Here is an illustrative case, not a quote. A company wants an AI assistant over its internal documents. One option is a tool at €40 per seat per month. The other is a €50,000 build on a bought model, with maintenance at 20 percent a year.
| Three year cost | Buy, 20 seats | Buy, 150 seats | Build, 150 users |
|---|---|---|---|
| Setup or build | €3,000 | €3,000 | €50,000 |
| Licenses or model usage, 36 months | €28,800 | €216,000 | €54,000 at €1,500 a month |
| Admin or maintenance, 3 years | €9,000 | €9,000 | €30,000 |
| Total | €40,800 | €228,000 | €134,000 |
| What you own at the end | An account and an export | An account and an export | Code, prompts, evals and the data pipeline |
At 20 seats, buying wins clearly. The build and its maintenance alone come to €80,000 before any model usage. At 150 seats, the build costs about 40 percent less over three years, and you own what you paid for.
Change the inputs and the answer moves. Model usage depends on volume, and a busy system can cost more than this to run. The tool may also do more than you would build. The crossover is the point. Per-seat costs scale with headcount, and build costs mostly do not. Run the same table with your own seat count, usage and quotes before anyone signs anything.
Data, differentiation and compliance
Data decides more of these calls than cost does. If a general model with public knowledge does the job, buy. If the answers depend on your contracts, product data, tickets or records, the system needs retrieval over that data. Then the real question is whether a product can connect to it properly, or whether you need to build that layer.
Differentiation follows from data. A capability every competitor can buy from the same vendor is parity. That is fine for internal productivity. It is a weak position for anything customers pay you for.
Compliance cuts both ways. Buying does not move your obligations to the vendor. Under the EU AI Act, classification follows the use case, not the model or the hosting. As the deployer, you keep your duties whether you built the system or bought it. Under GDPR, the vendor is your processor, so its regions, subprocessors and retention become your concern too.
Most business software is limited or minimal risk under the Act. That includes internal copilots, document search and support assistants. The main duty there is telling people they are dealing with an AI, which has applied since 2 August 2026. Where the use case touches hiring, credit, education or critical infrastructure, high-risk obligations apply from 2 December 2027. They require logging, human oversight and technical documentation. A product that cannot give you those forces a build, or a different product.
EU data residency is rarely the deciding factor on its own any more. The major models run on EU region endpoints through AWS Bedrock, Azure OpenAI and Google Vertex AI. Many products offer EU hosting too. What decides it is whether you can verify the answer. A build lets you choose and check. A product asks you to trust its documentation, so read it closely.
Switching cost, the line nobody budgets
Every AI decision gets revisited. New models arrive several times a year, vendors change pricing, and products get acquired or shut down. Price the exit at the start, while you still have bargaining power.
With a bought product, switching means exporting data, prompts, configuration and history, then retraining staff on something else. Check what the export actually contains before you sign. The EU Data Act requires cloud and SaaS providers in its scope to support switching. From 12 January 2027 it also bans switching charges. It does not make a poor export format usable.
With a build, the main switching cost is the model. Keep a thin layer between your code and the provider, and keep an eval suite that runs against any model. Then a model change is a test run, not a rewrite. The other switching cost is the team. If you cannot hand the code, runbook and evals to another team, you bought lock-in from your developers instead.
How often the honest answer is buy
Often. When we score a company's list of AI use cases, most items end as buy. Some turn out to be a configuration job on a tool already paid for. Usually two survive as candidates for real engineering, and one of those is often not the one people expected.
That is not modesty. Building something a vendor already sells for a few hundred euros a month is a poor use of budget. It also slows the build that matters, because engineering attention is finite and the second project always takes it from the first.
Our AI readiness assessment makes this call for each use case. It takes two weeks and costs €9,500 to €14,000. It ends in a written document with a build or buy call per candidate and one costed first build. If we build what it recommends within six months, on a project above €50,000, the fee comes off the first invoice. If the answer is buy, you keep the document and owe us nothing more.
Whichever way it lands, decide on a three year view, own your data and prompts, and price the exit before you sign.