AI Strategy

/

The AI Investment Trap: Why Build vs Buy Is the Wrong Question

AI investment strategy fails when teams pick build or buy too soon. Data on cost overruns, failure rates, and the hybrid approach that works.

/

AUTHOR

Ralf Klein
The AI Investment Trap: Why Build vs Buy Is the Wrong Question

The average enterprise AI project runs 2.7 times over its initial budget, and over 80 percent of organisations report no meaningful enterprise-wide EBIT impact from AI despite widespread adoption, according to McKinsey's 2025 State of AI report. The deeper trap is not that companies are bad at AI. The trap is that most of them treat the AI investment decision as a binary choice between building a custom system or buying an off-the-shelf tool, and pick the wrong side before they understand what they actually need.

Most internal AI teams and agencies walk into this fork with the same script. The CTO wants to build. The CFO wants to buy. Procurement runs a vendor shortlist, engineering scopes a custom platform, and six months later the company has either an unfinished prototype no one owns or a SaaS subscription that solves the wrong problem. Both outcomes burn capital. The companies that get AI investment right are not better at picking sides. They are better at sequencing.

The Real Failure Numbers

The visible part of the AI failure rate is bad enough. Gartner predicted that 30 percent of generative AI projects would be abandoned after proof of concept by the end of 2025. Subsequent surveys put the number higher: roughly half of generative AI pilots never reach production, killed off by poor data quality, weak risk controls, or unclear business value.

The hidden part is worse. Cost overruns average 380 percent at production scale versus pilot projections, and infrastructure constraints alone account for 64 percent of scaling failures. Most teams budget for the model and the engineers. They do not budget for the integration work, the monitoring, the access controls, the legal review, or the version of the model they will need to swap in eighteen months from now.

This is the trap. Companies frame the decision as build versus buy when the real question is whether they have any reliable way to measure value before they commit to either path.

Why Build Costs More Than You Think

The pitch for building is appealing: own the IP, control the roadmap, avoid lock-in. The reality is that a custom AI build in 2026 ranges from 50,000 to 100,000 dollars for a basic MVP, and 250,000 to 400,000 dollars or more for a full multi-agent system. A first custom project, like an LLM-powered support chatbot, typically lands between 30,000 and 80,000 dollars.

Those are the launch numbers. The post-launch numbers are where build economics fall apart. Industry analyses consistently show that roughly 65 percent of total software cost occurs after initial deployment. For AI specifically, that ratio is worse, because models drift, prompts need re-tuning, datasets need refreshes, and underlying providers change pricing or deprecate APIs. A 2.7x budget overrun is not a story about bad estimating. It is the standard cost shape of a system that nobody planned to maintain.

Build is the right move when the AI capability is the company's core differentiator, when off-the-shelf options genuinely cannot meet the requirement, and when the company can fund 2 or more dedicated engineers for several years. Outside those conditions, building is usually a slow and expensive way to recreate something that already exists.

Why Buy Fails More Often Than It Should

Buying looks cheaper. Most SMBs spend between 500 and 5,000 dollars per month on off-the-shelf AI tools, and enterprise tier subscriptions from major vendors run 5,000 to 50,000 dollars per month. Compared to a six-figure build, the SaaS option looks like a rounding error.

Then the bill grows. Per-seat pricing scales with adoption. Per-call pricing scales with traffic. Vendor roadmaps move in directions that do not match the company's needs. A 2025 Gartner survey of marketing technology leaders found 45 percent saying vendor-offered AI agents failed to meet promised business performance. The buy path turns expensive in two ways: the variable cost of usage at scale, and the hidden cost of changing direction when the vendor stops solving the problem.

Buy is the right move when speed-to-validation matters more than customisation, when the use case is generic enough that a vendor with hundreds of customers has already optimised for it, and when the company cannot reliably specify what it needs. Outside those conditions, the SaaS bill becomes the real opportunity cost.

Where Agencies Make It Worse

Agencies amplify both failure modes. The build-side agency wants to scope the largest project that resembles the brief, because revenue scales with engineering hours. The buy-side reseller wants the highest-tier subscription, because commission scales with deal size. The client ends up with the most expensive version of whichever path the agency happens to specialise in, regardless of whether that path fits the use case.

Gartner predicts that over 40 percent of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls. Agencies are not innocent bystanders in that statistic. Many of those projects were sold as transformation programmes when the underlying problem could have been solved with a 200 dollar per month tool and three weeks of process redesign. The cancellation comes at the moment the client realises this. The damage is the twelve months of agency invoices in between.

The signal that an agency is set up to actually solve the problem rather than maximise its own billings is simple. They are willing to recommend an off-the-shelf tool when one fits, and they have a written threshold for when they would tell a client to stop a custom build. If the agency does not have those two answers ready, the client is the product, not the customer.

The Hybrid Sequence That Works

The companies shipping AI most effectively in 2026 do not treat build versus buy as a one-time decision. They treat it as a sequence. They buy first to validate the use case with real users at low risk. They measure usage, retention, and the actual cost curve, not the projected one. Only when usage exceeds the economic break-even point, or when the vendor cannot move fast enough on requirements, do they commission a custom build.

The break-even maths is more concrete than most teams realise. If projected SaaS spend exceeds roughly 10,000 dollars per month and is growing, a 150,000 dollar custom build typically pays for itself within 15 months. Below that line, building is almost always a worse use of capital than the boring SaaS subscription.

The sequence also flips the failure mode. A 49 percent pilot-to-production failure rate is catastrophic when the pilot is a custom build, because the spend is sunk. The same failure rate is acceptable when the pilot is a SaaS subscription, because cancellation is a single click. Build commitments should follow validated demand, not precede it.

The Practical Takeaway

The investment trap is not picking build or buy. The trap is picking either one before the company has a quantified, observed answer to two questions: how much will this be used, and what does it cost per unit of use. Without those two numbers, both decisions are bets in the dark.

Before any AI investment of significant size, the team should be able to state the expected monthly active users, the expected cost per active user, the expected revenue or saved cost per active user, and what each of those numbers would have to be for the project to fail. If the team cannot answer those questions, the project is not ready to be a build, and not ready to be a buy. It is ready for a 30-day cheap pilot using whatever vendor delivers fastest.

The AI investment trap closes around companies that confuse confidence with commitment. Confidence comes from data the team has actually observed in production. Commitment is what comes after that. Most failed AI projects had those two steps reversed.