AI Is Repricing the Enterprise Build-vs-Buy Decision

The build-versus-buy question used to be simple arithmetic. Custom software cost more and took longer, so enterprises bought packages and built only what vendors would not sell them. AI is repricing both sides of that equation.

Coding agents, open models, and API access to commercial models are reducing the effort required to produce custom software, while vendors embed AI features into the packaged applications enterprises already license. McKinsey’s latest global survey finds 88% of organizations now use AI in at least one business function, and 23% are scaling AI agents somewhere in the enterprise. The decision in front of technology leaders is no longer whether AI is available. It is where each capability should come from, and who should operate it.

Is AI Making It Cheaper to Build Software Instead of Buying It?

Yes, for some use cases, because AI is reducing the engineering effort required to turn a requirement into working software.

That matters most for internal tools, integrations, and workflow automations, where development cost can determine whether a project clears the business case at all. The shift is already showing up in productivity data: Deloitte estimates gains of 30% to 35% across the software development life cycle, while the Stanford AI Index cites research showing gains near 26% on software development tasks.

Those gains lower the entry price of building, but they do not eliminate the cost of maintaining, securing, integrating, and governing the software once it exists.

When Should a Company Build Its Own AI Instead of Buying It?

A company should build when the capability depends on something competitors cannot easily buy, such as proprietary data, specialized process knowledge, or a workflow that creates meaningful differentiation. That is why the strongest build cases are rarely generic productivity tools.

McKinsey’s research on AI-native companies reduces the principle to building only what makes the company “truly distinctive,” because proprietary process context is often what makes an agent useful inside a specific business. Building also requires the organization to operate what it creates, including engineering, governance, and long-term maintenance.

Capabilities that do not depend on that unique context are stronger candidates for buying or adopting from an existing platform.

Is Building AI Really Cheaper Than Buying It?

Building AI is not automatically cheaper because the initial development cost is only one part of the economics. A custom application can avoid a software license yet still create recurring expenses for model usage, infrastructure, monitoring, security, integration, and maintenance.

Those costs can also move with the workload itself. Deloitte’s analysis of AI token economics shows how model choice, prompt design, and usage volume can make consumption-based costs variable, while its modeling finds self-hosted infrastructure can become substantially cheaper than API access at sufficient scale. The comparison therefore changes with utilization.

Companies need to model the lifetime cost of running a workload, not simply compare a development budget with a subscription price.

How Should Data, Security, and Vendor Lock-In Affect the Build-vs.-Buy Decision?

Data, security, and lock-in should determine which sourcing options are acceptable before companies compare price or speed. Building can provide more architectural control, but it also makes the enterprise responsible for a wider AI supply chain that may include external models, adapters, libraries, and infrastructure.

OWASP identifies model provenance, third-party components, licensing, and supplier risk as part of that exposure. Buying changes who operates parts of the stack, but it does not remove the customer’s responsibility for data use, access, integration, and vendor oversight. That is why NIST’s Generative AI Profile treats third-party risk as part of AI governance.

The practical question is how much dependency the business can tolerate and how easily it can change providers later.

Is Build vs. Buy Becoming Build, Buy, or Partner?

Yes, because enterprises increasingly assemble AI capabilities from multiple sourcing models instead of choosing one approach for the entire stack. A company might build the workflow that contains its proprietary process knowledge, buy the underlying model, and rely on a partner to integrate it with enterprise systems.

That pattern is already visible in current adoption research: 57% of organizations in KPMG’s AI Pulse Survey favored a blended approach to acquiring AI agents. Existing software also creates another route, because companies can adopt AI functionality already embedded in platforms they license; Deloitte treats that as a distinct sourcing option.

Build versus buy is therefore becoming a workload-level allocation decision, not a single enterprise-wide choice.

What This Means for SAPinsiders

• Custom AI is an architecture commitment. Every built agent adds model dependencies, data paths, and control surfaces to the system landscape. Build proposals should therefore be evaluated as integration designs with lifecycle costs attached.
• Metered AI spending needs utility-style governance. Token consumption can make AI costs behave more like variable infrastructure spending. Per-workload budgets, monitoring, and cost-allocation rules should be defined before usage scales.
• Benchmark scores do not equal enterprise readiness. Generic model performance says little about handling a company’s exceptions, approval paths, and control requirements. AI should be validated against the processes where errors carry real business consequences.