Build or Buy: Your Own AI Solution or Platform AI from SAP and the Like?

SAP promotes Joule, Microsoft the Copilot, Salesforce Agentforce. And in parallel, every development agency assures you that a bespoke AI solution is the only sensible path. Both sides earn money from their recommendation. Your problem is a different one: What is the AI already contained in your existing systems good enough for? And where does the effort of an in-house build genuinely pay off? This guide provides a decision logic along four criteria: differentiation value, total cost, data sovereignty, and exit costs.

What Build or Buy Means for AI

Build or Buy (also Make or Buy) describes the choice between an in-house solution and the purchase of a ready-made one. For AI, this means concretely: Either you use the AI features that platform providers such as SAP, Microsoft, Salesforce, or ServiceNow build into their products. Or you develop your own application based on language models, which you integrate via an API (a programming interface through which software accesses the model) or as a self-hosted open-source model.

What matters is the right altitude. Build or Buy is not a company-wide decision but a decision per use case. The same company can sensibly rely on Microsoft Copilot for summarising emails in the inbox while building the quotation calculation that constitutes its core business as its own solution. Anyone who decides across the board decides wrongly in half of all cases.

What Platform AI Delivers — and What It Does Not

Platform AI is AI functionality that a software provider integrates directly into its existing product. SAP Joule answers questions about business data in the SAP context, Microsoft Copilot works in Word, Outlook, and Teams, Salesforce Agentforce automates processes in the CRM. The strengths are obvious. The integration into the data sources is pre-built, the provider takes care of operations and model updates, and the introduction is more of a rollout project than a development project.

The limitations are just as real but are mentioned less often in sales:

• The provider determines the roadmap. Which features arrive, which models are used, what is discontinued: you have no influence over this.
• Platform AI ends at the platform boundary. Processes that run across multiple systems are only partially represented by a single Copilot.
• Standard remains standard. The feature you use is used by your competitor in identical form. No advantage arises from this.
• Depth of customisation is limited. Your own business logic can often only be introduced via the designated extension points, and these extensions are then in turn platform-bound.

Nevertheless, the following holds: For standard tasks without differentiation potential, platform AI is in most cases the more economical choice. How existing platform features can be systematically unlocked and cleanly configured is described under Platform Agents.

What In-House Development Means Today

“Build” today almost never means training your own language model. For the vast majority of companies this is neither necessary nor economically viable. In practice, in-house development means something else: building your own application around an existing model. Typical building blocks are RAG (Retrieval-Augmented Generation, the model is provided with relevant documents from your own holdings as context before answering), your own agent logic (AI systems that autonomously work through multi-step tasks with tool access), and integrations into your own system landscape.

This significantly lowers the barrier to entry. But it does not remove it. An in-house AI solution is software, and software has to be operated: monitoring, quality assurance of the outputs, model switches when a provider discontinues a version, security updates. Anyone who says “Build” also says “operations”. This point is regularly underestimated in decision proposals because the proof-of-concept stage does not yet make it visible. The honest truth is also: a considerable share of self-built AI solutions fails not because of the technology but because of a lack of maintenance after go-live.

Criterion 1: Differentiation Value

The first and most important question is: Is this use case a competitive factor or a commodity, that is, an interchangeable standard service?

Meeting summaries, email drafts, translations, standard reports: these are commodities. They do not make you better than your competitor; they merely prevent you from being worse. Developing these in-house ties up capacity without return. Buy.

The case is different when the AI touches a process that defines your business: the pricing of a wholesaler, the damage assessment of an insurer, the technical design work of a mechanical engineering firm. Here the value lies in your specific knowledge, and that is precisely what a generic platform cannot represent. A usable rule of thumb: If the process could appear in your annual report as a strength, examine Build. If it could appear in every job description in every industry, buy.

Criterion 2: Total Cost Instead of Licence Price

The most common mistake in build-or-buy calculations is comparing licence costs with development costs. Both are only excerpts. The calculation only becomes reliable as Total Cost of Ownership (TCO), the total cost over the period of use, typically considered across three to five years.

Two patterns from our project experience. With Buy, companies typically underestimate the introduction costs. A Copilot licence has little effect without a tidy data foundation and a clean permissions concept. With Build, the ongoing costs are typically underestimated because the calculation ends at go-live. As an order of magnitude: over the lifespan of a self-built solution, operations and further development often significantly exceed the initial development.

Criterion 3: Data Sovereignty

Data sovereignty describes the actual control over where data is stored, processed, and by whom it can be viewed. With platform AI, the provider processes your data in its infrastructure, governed by contract but outside your direct control. The major providers offer EU data regions and data processing agreements. For many use cases this is sufficient.

However, there are constellations in which this is not enough: health data, classified information, design data with a high risk of industrial espionage, or industries with regulatory requirements that effectively rule out processing outside your own infrastructure. Here the balance shifts towards Build, up to operating an open-source model on your own hardware, with all the consequences for cost and quality. Depending on the task, self-hosted models do not always reach the level of the major API models, and operating them requires specialist knowledge.

A second, often overlooked dimension: intermediate results also have a value. Anyone who feeds prompts, evaluation logic, and correction data into a platform for years builds up knowledge there that does not come along when leaving. This leads directly to the fourth criterion.

Criterion 4: Exit Costs

Exit costs are all the efforts that arise when you want to leave a solution again: data migration, rebuilding integrations and automations, retraining, parallel operation during the transition. They are the measure of vendor lock-in, that is, the dependency on a provider that makes a switch economically unattractive.

With AI platforms, lock-in arises more subtly than with classic software, because not only data is tied down but ways of working: configured agents, practised prompts, platform-specific extensions. Therefore, ask three questions before introduction:

• In what format do our data and configurations come back out, and is that contractually guaranteed?
• What happens to our processes if the provider discontinues the feature or raises the price substantially?
• How deeply do we interweave extensions with proprietary formats, and would there be a more portable alternative?

Build has exit costs too, for example the dependency on a model provider or on the people who built the system. A clean architecture keeps the model integration replaceable. That is a design decision that costs little at the start and is worth a great deal later.

The Decision in Practice: Usually a Both-And

The four criteria rarely all point in the same direction. A workable approach:

• Assess use cases individually. List the AI candidates and assess each one along the four criteria, not the company as a whole.
• Buy commodity cases, quickly and with discipline. Here time-to-value counts, not perfection.
• Examine differentiating cases before building. A limited pilot clarifies whether the expected value is real before operating costs arise.
• Take hybrid architectures seriously. Often the best solution is your own lean layer, for example an agent logic with proprietary knowledge that addresses platform systems rather than replacing them.

This assessment requires a role that can judge both worlds: realistically appraise platform capabilities while also quantifying the effort and risks of an in-house build. That is precisely the profile of an AI Architect, as an external, vendor-neutral capability often more sensible than a permanent hire, because the decision arises at a specific point in time, while operations afterwards require different profiles. Unclear terms from this guide are explained in the AI Glossary.

Conclusion

Build or Buy for AI is not a matter of faith but a portfolio decision per use case. The short form of the decision logic: Buy commodity features through the platforms you operate anyway, and build only where your specific knowledge makes the difference, data sovereignty compels it, or no platform represents the process. Calculate both paths as total costs over several years, and examine the exit costs before introduction, not when leaving. If you are unsure where a specific use case stands: a vendor-neutral architecture assessment is considerably cheaper than a corrected wrong decision, in either direction.