When Not to Use Machine Learning
5 min read · updated August 3, 2026
The useful version of “you might not need machine learning” is not a warning about hype. It is a set of conditions that can be checked in an hour, plus a formula whose inputs you either have or need to go and get.
Four preconditions
All four have to hold. Any one failing is a reason to stop, and the value of asking is that each is falsifiable rather than a matter of judgement.
- 1. A stable pattern exists. There is a real relationship between the inputs available at prediction time and the outcome, and it will still hold next quarter. Predicting a genuinely random outcome cannot work; neither can predicting one whose mechanism changes faster than you can retrain. The test: can a domain expert, given only the inputs, beat chance? If not, be suspicious.
- 2. You can obtain labelled examples. Enough of them, of the outcome you actually care about, available before you need the prediction. This is where most projects die, and it dies quietly, six weeks in. Count the labels and their cost first.
- 3. Errors are affordable and correctable. A fitted model is wrong on some fraction of cases, always, and you cannot enumerate which. If a single wrong answer is catastrophic or legally indefensible, either the model needs a human in front of the decision or it should not make it.
- 4. The obvious alternative is genuinely worse. Not assumed to be worse — measured. A rule, a lookup, a moving average, a five-feature logistic regression. If nobody has built one, you do not yet know whether you have a machine-learning problem.
The value formula
When all four hold, the remaining question is arithmetic. Everything here is an input you supply; nothing is a claim about your situation.
annual value = N × Δq × v − C_build/T − C_run − C_maintain N decisions per year Δq improvement over the baseline, in whatever unit the decision pays in v value of one unit of that improvement C_build one-off build cost, amortised over T years C_run inference, infrastructure, monitoring per year C_maintain retraining, drift response, on-call, the eventual migration
A worked example, with every number labelled as an assumption: 100,000 decisions a year; the model is 3 percentage points more accurate than the current rule; each additional correct decision is worth €2. Then 100,000 × 0.03 × 2 = €6,000 a year of gross value. Against a build cost of €40,000 amortised over two years — €20,000 a year — before you have paid for anything to run. The project is decisively negative and the arithmetic took a minute.
Change one input and it flips: at 10 million decisions the same three points is €600,000. That is the real lesson of the formula. Machine learning is a fixed-cost technology, so its economics are almost entirely about N, and a small accuracy gain on an enormous volume beats a large gain on a small one every time.
The term people forget is C_maintain. A deployed model needs monitoring for drift, a retraining path, someone who understands it when it misbehaves at 3am, and a plan for the day its feature pipeline changes. Budget it explicitly or it will be paid for out of somebody else’s roadmap.
Things that are not ML problems
| Situation | Description |
|---|---|
| the answer is a lookup | If the mapping is known and enumerable — tax rates, shipping zones, entitlements — it is a table and a join. A model would approximate a function you already have exactly, and be wrong sometimes. |
| an expert can state the rule | If someone can write it down in five lines, write those five lines. They are auditable, testable, instantly changeable and correct on the edge cases you care about. Revisit only when the rule list passes a few dozen entries and starts contradicting itself. |
| you have a few dozen examples of the event | Below a few hundred positive examples, the error bar on any estimate of quality is wider than the difference you are trying to detect. Spend the effort on collecting rather than modelling. |
| the decision needs a stated reason | Credit, hiring, benefits, medical triage. Either use an interpretable model whose logic is the reason, or keep the human decision and use the model to prioritise the queue. |
| the target changes weekly | Fraud tactics, spam, market regimes. Not never — but the project is a retraining pipeline first and a model second, and if you cannot fund the pipeline, do not start. |
| nobody has defined success | If there is no metric and no baseline, there is no way to know whether the model works, which means there is no way to know when to stop. This is the most common failure and the least technical. |
The baseline you have to beat
Build it first, in an afternoon, and put it in the same table as every model you ever report. There is a standard menu:
- Majority class for classification — the 99%-accurate model that catches nothing is precisely this, and it exists to embarrass an accuracy metric.
- Last observed value for time series. Surprisingly hard to beat, and a forecasting model that does not beat it is not a forecasting model.
- The current rule, whatever ships today. This is the only baseline that answers the question the business is actually asking.
- Logistic regression on five features. Fast, honest, and it establishes how much of the signal is linear — if it gets 90% of the way, the remaining complexity is buying very little.
What pretrained models changed
One term in the formula moved, and it is worth being precise about which. For text, image and audio tasks, C_build collapsed: a zero-shot or few-shot prompt to a pretrained model is a working baseline in an afternoon, with no labels, no training pipeline and no feature engineering. Problems that were not worth €40,000 of build are worth an afternoon.
But C_run went up, and it is now proportional to N rather than fixed. A per-token price times a million decisions is a recurring line that a trained-once classifier does not have. So the two options have genuinely different shapes: the pretrained model wins at low volume and while you are still learning what the task is, and a small trained model — or a fine-tune — can win once the task is stable and the volume is large. The crossover is computable, and it is the same kind of arithmetic as everything else on this page.
What did not change: preconditions one, three and four. A pretrained model does not make an unpredictable outcome predictable, does not make an unaffordable error affordable, and does not excuse you from building the baseline. It has made the second precondition — labelled data — far weaker, and that is genuinely a large change, but it is one change and not four.