Build vs. Buy

Build means developing in-house: the company creates its own applications on top of existing AI models and runs them itself. Buy means purchasing a finished product, today usually as software-as-a-service with fees per user or per use. In between sits the combination, often called blend: a purchased standard product does the task, and an in-house component connects it to data and workflows no product knows about. With AI, building almost never means training your own language model. What gets built are applications, interfaces and workflows around existing models.

The question is familiar from the classic make-or-buy decision in procurement and IT. With AI, the math shifts. Building has become cheaper because capable models are available through APIs and AI helps with the coding. Running a system costs as much as with any other software: access, permissions, security, bug fixing and keeping up with new model versions. On top of that, models change faster than traditional software, and that affects both paths.

That is why build vs. buy is not an IT detail for leadership. The decision determines who will still maintain a system three years from now and how expensive a later switch will be. Where company data flows depends on it too. The decision is made over the full lifetime, not on the price on day one.

Three questions carry the decision.

Every vendor comparison starts with the specific use case: which inputs get processed, which data sources are involved, who approves and where the result goes. Without that short list, people end up comparing feature lists instead of work.

After that, three questions help. First: does the task reflect something specific to the company, or do other firms handle it the same way? If the task is standard, such as scheduling, translation or general writing, a good product usually solves it better than an in-house build. Second: do several applications need the same capability, for example the same access to customer data or the same review rule? Then a shared in-house foundation tends to pay off more than many separate products that each solve it on their own. Third: does the company have people who will run, maintain and secure the system for the long haul, well past launch? Without lasting ownership of operations, building is off the table, however cheap development looks.

If the task is standard and only one application needs it, almost everything points to buying. If several applications share the capability and operations are covered, building or a blend deserves a closer look.

The math covers the full lifetime.

The comparison is total cost over the period of use, known in business as total cost of ownership. The purchase price or the first development contract is only the entry point. A purchased product is ready to use quickly, but it brings ongoing license or usage fees, customization to your own workflows, interfaces to existing systems and training. An in-house build is only usable once it has been developed, and after that it costs operations, monitoring, bug fixing, security updates and adapting to new model versions. Both sides add model costs, which many providers bill by units of processed text (tokens) and which rise and fall with usage.

One item often gets skipped: the exit. What does it cost to take the data along, change the workflows and retrain staff on another system? This question is cheapest to settle at the start, while the contract is still being negotiated. For cloud and SaaS services in the EU, the Data Act has set rules for switching providers since September 2025; whether a specific contract falls under them needs to be checked case by case.

Blanket rules of thumb, such as fixed percentages for maintenance costs, do not replace this calculation. Projects differ too much for that.

Both paths create dependency, just of different kinds.

Buyers depend on the vendor’s pricing, interfaces and roadmap. If the vendor changes its pricing, drops a feature or swaps the model in the background, your own workflow changes with it. This is called vendor lock-in. With AI it weighs more than with most other software, because the underlying models change quickly and a product tied to one model cannot use a better or cheaper one.

Builders depend on their own people and what they know. If the knowledge about a system sits in one or two heads, every resignation and every vacation becomes an operational risk. Good in-house builds are therefore documented, more than one person understands them, and a layer of their own separates the applications from the model. That way the model can be swapped without rebuilding every application.

Which dependency is acceptable depends on the workflow. A process close to the core business, one that customer relationships or pricing rely on, deserves more control. For standard reports, a product someone else maintains is enough.

What to settle before signing.

Whether you buy or blend, some questions are worth asking before the contract, because a demo rarely answers them. Which data leaves the company, where is it processed, and does the vendor use it to train its models? Which AI model runs in the background, and will the customer be told when it changes? Can data, templates and results be exported in an open format? Is there an API for connecting your own systems? How is pricing structured, and what happens if usage rises sharply?

Building needs an honest checklist too. Who looks after the system when the person in charge is on vacation? Where is it documented how it works? How are access and permissions granted, and who checks that they are still correct? How is a model switch tested before it goes live?

The answers belong in writing in the decision memo. They show which dependency the company is taking on, and they are the basis for reviewing the decision after a year or two. Evasive answers from a vendor are a finding in themselves.

What a good decision looks like.

A sound build-vs.-buy decision can be explained in a few sentences and holds up to follow-up questions. The use case fits in one sentence. The comparison rests on a trial with a real task, real data and the real approval step, not on a vendor demo. Costs are calculated over the full lifetime, including the exit. It is clear who will look after the system after launch. It is also settled where the data goes and which model processes it, because data protection rules and the EU AI Act apply to purchased and in-house systems alike.

Warning signs are the opposite. A tool gets bought because the demo was convincing. An in-house build starts because someone is excited about the project, with no plan for running it. Or every new use case brings another subscription, until data, contracts and costs are scattered across many vendors. At that point the shared capability already exists, just in fragments, and the question of a common foundation comes up again.

Where the term stops working

Build vs. buy answers who develops and runs an AI system, not whether the project is worth doing at all; that is what AI ROI is for. Fine-tuning, meaning adapting an existing model with your own data, is a technique that can show up on either path, not a path of its own. The same goes for low-code platforms: they speed up building but do not change the fact that the company runs the system.