Build vs buy software in the age of AI: how to make the right call

The build vs buy question has always been difficult. AI has made it significantly more consequential.

The variables that used to govern the decision, cost, speed, and customisation, still matter. But AI has introduced new ones: vendor lock-in tied to data pipelines, IP ownership of model outputs, data sovereignty at a regulatory level, and API costs that look manageable at low volume and punishing at scale.

Most frameworks for this decision were written before those variables existed. This article is the updated version. It covers what AI has changed, when each direction makes sense, and a clear framework for making the call before committing budget.

Key takeaways

• The build vs buy decision in the AI era is a strategy question, not just a cost question
• Buying makes sense when speed matters more than differentiation and the capability is not central to how you compete
• Building makes sense when the use case is tied to competitive advantage, the data is sensitive, or API costs at production scale exceed the cost of building equivalent infrastructure
• A third option, building on top of bought infrastructure, is often the most commercially sensible approach and the one most organisations overlook
• Vendor lock-in in an AI context is more consequential than in traditional SaaS because it extends to data pipelines, model outputs, and IP ownership
• The honest financial comparison runs over three to five years, not just the upfront cost

The classic build vs buy framework assumed that off-the-shelf software was stable, well understood, and feature-rich enough to cover most business needs. That assumption held reasonably well for a decade of SaaS growth.

AI has disrupted it in three specific ways.

First, vendor dependency now extends beyond features. When you buy an AI capability, you depend on the vendor's model, their infrastructure, their data handling policies, and their pricing decisions as your usage scales. That is a different kind of dependency from a CRM subscription.

Second, the pace of AI capability change means that a buy decision made today may be commercially inferior within eighteen months. A competitor who builds their own capability can iterate continuously. A competitor locked into a vendor roadmap cannot.

Third, the build vs buy framework McKinsey and others have historically described treats the decision as binary. In the AI era, it rarely is. The most commercially intelligent decisions tend to sit between the two extremes.

Buying is the right decision in more situations than most technology teams want to admit. Speed is real. An off-the-shelf AI solution can be deployed in weeks rather than months. For a business that needs to move fast and does not have the internal capability to build and maintain a production-grade AI system, buying is often the correct call.

Buying also makes sense when the capability is not tied to competitive differentiation. If every business in your sector has access to the same AI tool on the same terms, deploying it still delivers operational value. It just does not create a competitive moat.

A 2026 report found that 71% of tech teams choose off-the-shelf solutions to accelerate time to value. That figure reflects a genuine commercial reality. For non-core capabilities where speed of deployment matters more than customisation, the AI buy decision is often faster, cheaper, and lower risk than building.

Most vendor evaluations focus on features, pricing, and integration. They rarely focus on what happens after the contract is signed and the usage grows. These are the risks that consistently show up later.

Vendor lock-in

Vendor lock-in in an AI context is more serious than in traditional software. Switching a CRM is painful. Switching an AI platform means migrating data pipelines, retraining workflows, potentially losing model outputs you thought you owned, and rebuilding integrations from scratch. The cost of switching tends to increase in direct proportion to how deeply the AI is embedded in your operations.

API costs vs infrastructure build

API costs look manageable at low volume. At production scale, they compound quickly. Businesses that model their AI buy decision on early-stage usage figures frequently discover that their costs at full deployment exceed what an equivalent custom infrastructure would have cost to build and run. Building the comparison honestly over three years rather than three months changes the outcome of the analysis in many cases.

Data sovereignty

When your data enters a vendor's AI system, the questions that matter are: where is it processed, who can access it, what jurisdiction applies, and who owns the outputs the model generates from it. For businesses in regulated industries, or those handling sensitive customer data, data sovereignty is a board-level concern rather than a technical detail. Many organisations discover this after they have signed, not before.

Competitive moat

If your competitor can access the same AI capability by signing the same vendor contract, it is a commodity. It improves your baseline performance. It does not create an advantage. For AI applications that sit at the heart of how you deliver value to customers, buying a shared platform means your competitors are running on the same engine.

Building makes sense when the use case is directly tied to how you compete and when the data involved is proprietary enough that a generic model cannot match what a custom one would deliver.

IP ownership is the underlying principle. A custom-built AI system, trained on your data, optimized for your specific workflows, and owned outright by your business, creates a capability that cannot be replicated by a competitor signing a vendor contract. Custom LLM fine-tuning is one of the clearest examples: a model fine-tuned on your proprietary data performs significantly better on your specific use cases than a general-purpose model accessed via API, and the advantage widens over time as more data accumulates.

Building also makes sense when the long-term economics favour it. API costs at production scale, combined with vendor price increases as your dependency deepens, frequently make custom infrastructure the cheaper option over a three to five year horizon. The build decision looks more expensive in month one. The buy decision often looks more expensive by year three.

Most organisations frame this as a binary choice. Build everything or buy everything. In practice, the most commercially sensible approach for many AI investments sits between the two.

The hybrid model means buying the foundational infrastructure and building the differentiated layer on top of it. Use a foundation model via API for the commodity AI work. Build the proprietary fine-tuning, the custom data pipelines, and the workflow integrations that reflect your specific operational context. The foundational capability is shared with the market. The layer built on top of it is not.

This approach captures the speed advantage of buying while preserving the IP ownership and competitive moat that building creates. It also limits API cost exposure because the commodity work is handled efficiently at the foundation layer, while the proprietary value sits in the custom build that your business owns outright.

These questions cut through the noise faster than any framework. Answer them honestly before committing to either direction.

1. Is this capability directly tied to how we compete?
If the answer is yes, buying a shared platform puts your competitive differentiation in someone else's hands. If the answer is no, buying is almost always the faster and more sensible route.

2. How sensitive is the data this system will process?
Data sovereignty and regulatory compliance obligations need to be established before any vendor evaluation begins, not after. For highly sensitive data, the question of where it goes and who owns the outputs may make the buy decision untenable regardless of the feature comparison.

3. What are the realistic API costs at our projected usage volume in year two and year three?
Model this honestly before the decision is made. Hidden integration costs add significantly to buy decisions at scale, and most initial estimates do not account for how usage patterns change once a system is embedded in daily operations.

4. Do we have the internal capability to build and maintain this long-term?
Building requires not just development capability but ongoing operational discipline. Monitoring, retraining as data patterns shift, and iterating as requirements change are all part of the long-term cost. If that capability does not exist internally, buying is the lower-risk option until it does.

5. How much will we need to customize the solution to fit our actual workflows?
Vendors build for the median customer. If your workflows differ significantly from that median, the customisation cost on top of a buy decision frequently exceeds the cost of building something that fits from the start.

6. What happens if this vendor is acquired, pivots, or raises prices significantly?
This is the vendor lock-in question in its most practical form. Model the worst-case scenario before committing. If the answer creates serious operational or financial risk, that needs to factor into the decision.

7. Do we own the IP and model outputs, or does the vendor?
Read the contract carefully on this point. Some AI vendor agreements retain rights to model improvements derived from your data. IP ownership of the outputs your AI system generates is a commercial and legal question that belongs in the initial evaluation, not in a legal review two years later.

8. Is this a capability we want to own permanently, or one we want to internalize over time?
Some businesses buy initially to learn and build internal capability, then transition to a custom build once they understand the domain well enough to specify it properly. This is a legitimate strategy and worth building into the plan from the start rather than discovering it as an unplanned migration later.

Vendor lock-in in traditional software is expensive. In AI, it is more consequential because the dependency runs deeper and the switching cost is harder to quantify upfront.

Lock-in manifests in several specific ways. Proprietary data formats that cannot be cleanly exported mean your data is effectively held by the vendor as long as you remain a customer. Model outputs that belong to the vendor rather than to you mean the value generated by your AI investment is not entirely yours. Pricing that increases as your dependency deepens means the vendor's leverage over you grows in direct proportion to how embedded the system becomes.

The strategic dimension matters too. A competitor with a custom-built AI capability can experiment, adapt, and improve continuously without waiting for a vendor roadmap. A business locked into a platform iterates on the vendor's schedule, not its own. Over time, that difference compounds into a measurable gap in how quickly each organisation can respond to market changes.

Data sovereignty adds a regulatory layer that is increasingly hard to ignore. The EU AI Act and similar frameworks are creating specific obligations around where data is processed, how AI decisions are audited, and what transparency is required. Understanding which jurisdiction your vendor operates in and what that means for your compliance obligations is not a detail to leave to the IT team.

Most build vs buy financial comparisons compare the wrong things. They put the upfront build cost against the initial subscription price and conclude that buying is cheaper. That comparison is accurate for month one and increasingly inaccurate for every month that follows.

The honest comparison runs over three to five years and includes every relevant cost on both sides.

On the buy side:

• Initial subscription or licensing cost
• Integration costs, which typically add 150 to 200% to the headline price
• API costs at projected production-scale usage in year two and year three
• Internal maintenance and management overhead
• The cost of switching if the decision proves wrong
• Vendor price increases as your usage and dependency grow

On the build side:

• Development cost including discovery, design, build, and testing
• Infrastructure and hosting costs at production scale
• Ongoing maintenance, monitoring, and model retraining
• Internal team cost to own and evolve the system
• The time cost of not having the capability available immediately

Neither side of this comparison is inherently better. The outcome depends entirely on the specific use case, the volume of usage, the complexity of the data, and how central the capability is to the business. Running the comparison honestly is what makes the decision defensible rather than optimistic.

The build vs buy question has never had a universal answer. AI has made the consequences of getting it wrong more significant.

Buying can give you speed and simplicity, or it can give you vendor lock-in, data sovereignty problems, and API costs that compound faster than anyone modelled. Building can give you a genuine competitive moat and full IP ownership, or it can give you a maintenance burden your team cannot sustain.

The framework in this article does not make the decision for you. It makes the decision better informed. And a better informed decision, made before budget is committed rather than after, is almost always the one that holds up.