Stop Building AI You Should Be Buying

Every organisation believes its problems are unique. In AI, this belief is particularly expensive.

I've seen a financial services firm spend eighteen months building a custom document processing system. An off-the-shelf solution would have covered 95% of their requirements at 10% of the cost. The remaining 5% — the genuinely unique part — could have been handled with a thin customisation layer on top. Instead, they built everything from scratch, hired a team of ML engineers they now can't retain, and ended up with a system that's harder to maintain than the manual process it replaced.

This pattern repeats across every sector. The 'unique requirements' that justify building are almost always either commodity requirements that the team hasn't benchmarked against existing solutions, or edge cases that don't justify the full build cost. The test is brutal but honest: if a competitor could buy the same solution and get the same results, you're not building competitive advantage. You're building unnecessary cost.

Build custom AI when — and only when — the system is core to your competitive differentiation and requires proprietary data that you can't share with a vendor.

That's a much smaller category than most organisations think. A recommendation engine trained on your proprietary customer behaviour data? Potentially worth building. An internal chatbot for HR queries? Buy it. A fraud detection system that learns from your specific transaction patterns? Maybe build it. An AI-powered content generation tool? Buy it.

The question to ask is: does this system get better specifically because it learns from our data, in ways that a shared model can't replicate? If the answer is no — if the system works just as well on generic data — then you're building commodity infrastructure and calling it strategy.

I worked with one senior figure who was convinced that custom-built AI was going to be their metaverse — the next transformational platform that would redefine their business. Six months and significant budget later, they had an internal tool that did roughly what three SaaS products already offered. The metaverse comparison turned out to be more accurate than they intended.

Buying isn't without risk, and the risks are ones that procurement teams consistently underestimate.

Vendor lock-in is the obvious one. Your workflows, your data, your integrations all become dependent on a vendor's roadmap and pricing decisions. When they raise prices — and they will — your switching costs are enormous. When they pivot their product in a direction that doesn't serve you — and they might — you're stuck.

The less obvious risk is capability atrophy. When you buy instead of build, you don't develop internal understanding of how the AI works, how to debug it, how to improve it, or how to replace it. You become dependent not just on the vendor's software but on their expertise. And when the contract comes up for renewal, they know that.

The mitigation is straightforward: buy solutions where the switching costs are manageable, the data remains yours, and the integration layer is something your team understands. Never outsource understanding.

Between building and buying, there's a third option that most organisations skip: partnering. Not outsourcing — partnering. The distinction matters.

Partnering means working with a specialist who builds capability with you, not just for you. The partner brings domain expertise and acceleration. You bring context and data. The output is something you own and can operate independently — not a dependency you can't escape.

This model works for the messy middle: problems that are complex enough to need specialist expertise but not core enough to justify building a permanent internal team. AI governance frameworks, custom model fine-tuning for your domain, GEO infrastructure, agentic workflow design — these are all areas where the partnership model consistently outperforms both building (too slow, too expensive) and buying (too generic, too rigid).

The organisations that get this right are the ones that treat AI partnerships like they treat legal counsel: specialist expertise on tap, institutional knowledge that accumulates over time, and a relationship built on shared outcomes rather than billable hours.