Machine Learning Myths That Waste Budgets

Where the money actually goes

Most machine learning budgets are not wasted on bad code. They are wasted on a belief held early in the project that nobody questioned, which then shapes six months of work. By the time the belief meets reality, the spend has happened.

We see the same handful of myths in proposals, board decks and supplier pitches. None of them is stupid. Each one is half true, which is exactly why it survives. Here are the ones that cost the most, roughly in order of damage.

Myth one: more data always makes the model better

More relevant, correctly labelled data usually helps. More data in general often does not. A retailer with eight years of sales history may find that anything before a major change in pricing or channel mix actively misleads a demand model, because the business it describes no longer exists.

The expensive version of this myth is a data warehouse project launched as a prerequisite to machine learning, costing more than the model would have, and finishing with a lake of history that is mostly irrelevant. Start with the question, then collect the data that answers it.

Myth two: accuracy is the number that matters

Accuracy is a convenient number and frequently the wrong one. A fraud model that labels every transaction as genuine will be 99% accurate if 1% of transactions are fraudulent. It is also useless.

What matters is the cost of each kind of mistake. Missing a fraudulent order might cost 200 pounds; wrongly blocking a good customer might cost the customer. Those two numbers, not a headline accuracy figure, decide where the threshold goes and whether the project is worth doing.

Myth three: once it is trained, it is done

A model is a snapshot of how the world looked when the training data was collected. Customers change, suppliers change, a competitor opens down the road. Performance drifts, usually slowly and silently.

Budgets built on the idea of a one-off build tend to run out just as the model needs its first retraining. A realistic plan includes monitoring, a retraining routine and someone who owns it. That ongoing cost is often 15 to 25% of the build cost per year in our experience, and it should be in the business case from the start.

Myth four: you need a data science team before you start

Hiring three data scientists before you have a validated use case is one of the more reliable ways to spend a year producing notebooks. People with nothing specific to solve will find interesting problems, which is not the same as valuable ones.

Most SMEs are better served by proving one use case with outside help, then hiring for the work that proof reveals. Often the first hire turns out to be a data engineer, not a scientist, because the real bottleneck was getting clean data out of three systems.

Myth five to eight, briefly

• 'The algorithm is the hard part.' Choosing between gradient boosting and a neural network rarely decides a project. Data preparation, integration and deciding what to do with a prediction usually do.
• 'Deep learning is better.' For tabular business data such as orders, customers and invoices, simpler methods are often as good, cheaper to run and far easier to explain.
• 'Generative AI replaced classic machine learning.' A language model is a poor choice for predicting next month's stock requirement. The two solve different problems and most useful systems in 2026 use both.
• 'If it works in the demo, it will work in production.' Demos use clean, hand-picked data. Production gets the messy Tuesday afternoon version.

How to spot these myths in a proposal

Myths rarely appear as stated beliefs. They show up as line items and phrasing, and once you know what to look for they are easy to find in a supplier's proposal or an internal business case.

• A phase called 'data consolidation' that costs more than the model and has no named question attached to it
• Success criteria written as a single accuracy percentage, with no mention of what an error costs
• No line for monitoring, retraining or support after month three
• A recruitment plan that starts before the first use case has been tested
• Architecture diagrams with a neural network in the middle and no explanation of why a simpler method was ruled out
• A demo built on a curated sample, with no plan for testing against last month's real records

None of these automatically makes a proposal bad. Each one is a question worth asking before you sign, and a good supplier will have a straight answer. If the answer is vague, treat that as information about how the rest of the project will go.

The myth underneath all of them

The root myth is that machine learning is the goal. It is a tool, and quite often the wrong one. Some problems are solved perfectly well by a rule, a report or a better form. We have a longer piece on when a rules engine is the better choice, and it is worth reading before any budget is signed.

When SpiderHunts scopes machine learning work, the first conversation is about the decision the model will change and what that decision is worth. If nobody can put a rough number on it, the project is not ready, however good the data is.

A model that is 95% accurate at a decision nobody acts on is worth exactly nothing.

Frequently asked questions