Classical ML where it fits: forecasting, classification, recommendation. We pick the simplest model that works.
What this covers
A great many problems presented as needing deep learning are forecasting, classification, or ranking problems that a well-specified classical model handles better. Better, not merely cheaper: simpler models are easier to explain to the people who must act on their output, easier to debug when they drift, and far easier to retrain on a schedule someone can actually maintain.
The decisive work is usually upstream of the model. Where the data comes from, how late it arrives, what happens when a source changes shape, whether the features available at training time will genuinely be available at prediction time — these determine the ceiling on performance long before the choice of algorithm does. A model trained on information it will not have in production is a common and expensive failure, and it looks excellent in evaluation.
So the approach is unglamorous on purpose: establish a baseline that anyone can reason about, make the pipeline that feeds it reliable and repeatable, and only add model complexity where it earns a measurable improvement against a decision someone is actually making.
A representative image for ML Consulting — a real system diagram, an architecture whiteboard, or the team at work. Not a stock photo.
No asset supplied yet
The shape of it
How we approach it
Identify the decision the model is meant to improve and what being wrong costs in each direction.
Build the simplest defensible predictor and measure it honestly. Everything later is compared against this.
Add complexity only where it beats the baseline on a metric tied to the decision, validated the way the data actually arrives.
Make retraining, monitoring, and drift detection routine rather than a project someone has to re-propose.
Principles
A trivial model — the seasonal average, the majority class, the most recent value — is the number every later model must beat. It is quick to build, and it regularly reveals that the sophisticated approach adds less than it costs.
Complexity has to earn its place against maintenance, explainability, and the risk of silent drift. A model whose behaviour can be explained to the person acting on it gets used; one that cannot gets quietly ignored.
Models are re-trained; pipelines are lived with. Reliable ingestion, honest handling of missing data, and features computed the same way in training and in production matter more to the outcome than the estimator.
Accuracy is not the goal — a better decision is. The metric should reflect what it costs to be wrong in each direction, because those costs are rarely symmetric and the default metrics assume they are.
Is this you?
A short walkthrough for ML Consulting — an engineer explaining the approach, or a screen recording of the system being discussed.
No asset supplied yet
The other three
We'll tell you straight whether this is the right thing to spend on.