When not to use machine learning

There's commercial pressure in the industry to recommend machine learning for everything, because "we built you an ML model" sounds more impressive than "we wrote you a SQL query." That pressure produces a lot of models that cost more than they're worth and solve problems that didn't need solving that way.

So here's a counter-position from people who build models for a living: a lot of the time, you shouldn't. Knowing when *not* to reach for machine learning is as valuable as knowing how to build it, and it's a sign of a partner who's optimising for your outcome rather than their invoice.

When a model is the wrong tool

When simple rules already work. If the logic is clear and stable, write the rules. A rules engine is explainable, debuggable, cheap to run, and doesn't need retraining. Reaching for a model here adds cost and opacity for no benefit.

When you can't measure success. If you can't define what a good prediction looks like and measure it on held-out data, you can't evaluate a model, which means you can't trust it. No measurable target, no model.

When you don't have the data. A model learns from examples. If you don't have enough relevant, reasonably clean historical data, no technique rescues that. Garbage in, garbage out is not a cliché here; it's the whole constraint.

When the stakes demand full explainability and the model can't give it. In some regulated decisions you must be able to justify every outcome precisely. If a model can't provide that and the context requires it, a transparent rules-based approach may be mandatory regardless of raw accuracy.

When a dashboard answers the question. Sometimes the business doesn't need a prediction at all, it needs to *see* what's already in the data. A clear dashboard or a well-framed analysis often delivers the decision the stakeholder actually wanted, faster and cheaper than any model.

When a model genuinely earns its place

Machine learning is the right tool when the pattern is real but too complex to write by hand, when it involves many interacting signals, and when you have the data to learn it and a way to measure success. Churn prediction, demand forecasting, anomaly detection, these are genuine ML problems because the patterns are multi-dimensional, shifting, and beyond hand-coded rules, and because you can measure whether the model works.

The test is simple: could a person write down the rule? If yes, write the rule. If the pattern is real but nobody could enumerate it, and you can measure success, that's where a model earns its complexity.

Why this honesty matters to you

Every model you deploy is a liability as well as an asset. It needs monitoring, retraining, and maintenance; it adds opacity; it's one more thing that can silently degrade. That ongoing cost is justified when the model delivers value a simpler approach can't. It's pure waste when a rule or a query would have done.

So the right first step on any data project isn't "let's build a model." It's an honest feasibility read: what's the real question, can the data support an answer, and what's the simplest thing that answers it? Sometimes that's a model. Often it's something cheaper, and a partner worth working with will tell you so.

Don't take anyone's word that you need machine learning, including a data scientist's. Ask what simpler approach was ruled out and why. If there's no good answer, you're buying complexity you don't need.