The pitch for off-the-shelf AI is seductive. Deploy in weeks, not months. No custom development. Proven at scale. A recognisable brand on the vendor slide. For leadership teams under pressure to show AI progress, it is an easy yes.

The costs arrive later. And they are rarely accounted for in the business case.

The friction of fit

Every organisation has developed its processes, its data structures, and its ways of working over years — shaped by its people, its market, and its identity. A generic AI tool is built for a statistical average of those organisations. The gap between that average and your specific reality is where the cost lives.

Sometimes the gap is small. A tool built for a process that is genuinely standard — invoice processing, basic customer routing — can often be deployed with acceptable friction. But the higher-value applications are rarely standard. Risk assessment, demand forecasting, resource allocation, clinical decision support — these are domains where the specifics matter enormously. A model trained on someone else’s data, making decisions calibrated to someone else’s environment, will be wrong in ways that are difficult to detect and expensive to correct.

The highest-value AI applications are precisely those where the specifics of your organisation matter most. That is also where generic solutions fail most expensively.

The adoption tax

Beyond model accuracy, there is the question of adoption. Generic tools require your organisation to change its behaviour to match the tool — rather than the tool adapting to fit the organisation. This is not merely an inconvenience. It is a fundamental misunderstanding of how change works in complex organisations.

People do not adopt tools that contradict their working patterns without significant pressure and significant management overhead. The adoption tax — the time, energy, and political capital required to push a misaligned tool into daily use — is rarely visible in the ROI model. It shows up in utilisation rates six months post-launch, in workarounds and shadow processes, in the quiet frustration of teams who were not consulted.

What the total cost picture actually looks like

When you account for the integration work required to connect a generic tool to your specific data infrastructure, the customisation that is invariably needed to make it useful in your context, the change management programme required to drive adoption, the ongoing cost of maintaining a tool that was not built for your environment, and the opportunity cost of decisions made on outputs that were calibrated for someone else — the picture changes.

This is not an argument against speed. It is an argument for honesty about what speed costs when the destination is wrong. A system built correctly from the beginning, even if it takes longer to deploy, compounds value continuously. A generic system that required significant remediation after launch compounds cost.

The alternative

Custom does not mean slow. It means starting from the right question: what does this organisation actually need, and what does it mean to build that well? Answered honestly, that question leads to faster adoption, more accurate outputs, lower total cost of ownership, and — most importantly — a system that the organisation can build on rather than work around.

That is the difference between a deployment and a foundation.