Start from the problem, not the tool. It is the most overused line in this whole field, and I almost hesitate to write it down, but it is repeated so often because it keeps being true: buying something first and then hunting for a use for it is the most reliable way to waste money on AI. For most needs the choice is not which of fifty products, it is which of a few well-known tools, used on the right tier and pointed at one real workflow, then piloted against a concrete before-and-after so you can see whether it actually paid off.
That sounds obvious, but the noise works against it. Every vendor now describes itself as AI-powered, the demos are persuasive, and the temptation is to choose by feature list. The cost of choosing badly is rarely the licence fee, though. It is the weeks of disruption, the tool nobody adopts, and the quiet loss of confidence when the first attempt visibly fails. UK evidence is consistent that the real barrier to getting value from AI is not budget but knowing which problem to point a tool at, so a good selection process is less about comparing features and more about being honest about where your time and money are actually leaking.
There are really only four kinds of AI tool
A simple way to cut through the market is to notice that there are really only four kinds of AI tool to choose between: a general assistant such as ChatGPT, Claude, Microsoft Copilot or Gemini, for open-ended drafting, summarising and analysis; an AI feature inside software you already pay for, like your CRM, accounting package or office suite, which avoids a new contract and new logins; a specialist tool built for one job, such as transcription or bookkeeping categorisation; and, rarely, a custom build on top of a model provider. Deciding which class you need collapses a market of hundreds into a shortlist of two or three.
For most small businesses, buy beats build
For most small businesses the honest answer is buy, not build, and that matters because building is where the money tends to disappear. MIT's widely-reported 2025 research found that AI tools bought from specialist vendors reached successful deployment around twice as often as tools built in-house. The economics point the same way: off-the-shelf tools typically run from roughly £20 to a few hundred pounds a month, whereas a custom build commonly starts in the low tens of thousands and then carries fifteen to twenty-five per cent a year in maintenance, with hidden costs (data preparation, integration upkeep, retraining) that can roughly double the true three-year cost. Those figures are indicative rather than precise, but the direction is not in doubt. This is also why I work the way I do: the craft is in designing how mature, well-supported tools are adopted around your problem, not in engineering a bespoke system from scratch. "Build vs buy" is really a spectrum, from off-the-shelf, to configuring something with no code, to letting a tool draw on your own documents, and most firms should stay near the simple end. Building is worth it only when the capability would be a genuine, durable advantage, depends on data competitors cannot replicate, or faces compliance constraints no off-the-shelf option can meet.
Check the data tier before the brand
Before comparing anything, run the data and security question first, because the tier you choose matters more than the brand. The same well-known assistant can be unsafe or safe for business data depending purely on the plan: several consumer tiers now use what you type in to train the model by default, while business, enterprise and API tiers generally do not. Anything touching client or commercial information belongs on a business tier, never a free personal login. (There is a fuller answer on this in the data and confidentiality FAQ.)
Score on fit, not on feature lists
With the class chosen and the data gate passed, score your two or three candidates on what actually decides success, rather than on feature lists: how well each fits the real workflow; how cleanly it integrates with the systems you already use; its data and security terms; the total cost of ownership including training and switching, not just the subscription; how easily the people who will use it can adopt it; and how painful it would be to leave if it disappoints. Integration, not raw model cleverness, is usually where the return is won or lost.
Prove it on a small pilot
Then pilot, do not purchase on faith. Run a small, time-boxed trial on one workflow, with a named owner and a fixed end date, measured against the before-and-after number you set out to move. If it beats the baseline and people use it, adopt it and write the workflow down. If it half-works, adapt the process or the tier. If it does not, drop it without sunk-cost guilt and move to the next problem. One process at a time is also how a team builds the confidence that the surveys keep naming as the real constraint.
How to avoid being oversold
A last word on not being oversold, because this is where money quietly goes. Overstating what a tool can do, sometimes called AI washing, is now a recognised risk that regulators act on: the Advertising Standards Authority, the Financial Conduct Authority and, in the United States, the FTC have all moved against exaggerated AI claims. Usefully, that puts the burden of proof on the seller, not on you. So the strongest protection is to start from your own problem rather than a vendor's demo, and then make them prove the tool on your own data and your messy real inputs, with what counts as good enough agreed in advance. A polished demo and a headline accuracy figure are the weakest forms of evidence, because both are measured on the vendor's terms rather than yours; a refusal to test on your data is a red flag worth heeding.
The costliest mistakes tend to be commercial rather than functional. Price the whole thing over two or three years, not the sticker: licence, set-up, integration, training, and the cost and practicality of leaving. Watch for lock-in that only shows up once a tool is embedded, and be wary of land-and-expand pilots that lower the entry price in exchange for a harder exit. Then protect yourself in the contract: your data is not used to train the supplier's model, you own the outputs, and you can export your data and leave cleanly. None of this needs technical expertise; it needs a little structured scepticism, applied early.
Approached this way, choosing a tool stops being a gamble and becomes a short, repeatable decision: one problem, the right class of tool on the right tier, scored on fit, and proven on a small pilot before you commit. If it would help to run that process on a real workflow in your business, a discovery call is a good place to start.