Machine learning is genuinely useful for problems where the rules are unknown, numerous, or changing. It is a poor choice for problems where the rules are known and stable, which is a surprisingly large share of what gets proposed.
The distinction matters because a model brings costs a rule does not: training data, evaluation, drift, latency, cost per call, and a decision that cannot be fully explained.
If the rule is writable, write it
Eligibility, pricing tiers, routing by category, validation — these usually have definitions that exist somewhere in a policy document. A rule engine gives a correct, auditable, instantly changeable answer. A model gives a probable one that needs retraining when the policy changes.
The temptation is real because the rules are often tedious to gather. Gathering them is still cheaper than the alternative.
Check whether you have the data
A model needs enough labelled examples, representative of production, covering the cases that matter. Many proposals fail here and the failure is discovered months in, after infrastructure has been built.
The rarest classes are often the most valuable ones, and they are exactly where the examples are thinnest. Establish that the data exists before designing around it.
Ask whether a probability is acceptable
Some decisions tolerate being right most of the time. Others must be explainable to a regulator, a customer, or a court. If a decision needs a reason rather than a score, a model is the wrong instrument regardless of its accuracy.
This is not a limitation to engineer around. It is a requirement that selects the approach.
Baseline against something trivial
Before any model, measure the simplest possible approach: the most common class, a keyword match, a handful of thresholds. A meaningful number of ML projects turn out to beat this baseline by very little, and that comparison is far cheaper to run at the start than at the end.
Where it genuinely earns its place
Unstructured input — language, images, audio. Patterns too numerous to enumerate, like fraud or recommendation. Problems where the relationship genuinely shifts over time. Ranking where a good-enough order beats no order at all.
In those cases the uncertainty is inherent in the problem, and a model is not adding it — it is managing it.
The interesting question is never whether a problem could be solved with machine learning. It is whether the resulting system would be better than the boring alternative once you have paid for all of it.