Ordering stock sounds straightforward until you’re responsible for it. Buy too little and customers leave empty-handed. Buy too much and you’ve paid good money to store things nobody wants yet. I wanted to build something that could help make that call.
I’m a backend Python engineer, not a data scientist, and retail forecasting was new territory for me. In under seven days, I built a working pipeline that takes sales history, compares three forecasting models, and uses the winner to recommend what to order. It includes data validation, an evaluation harness I built, inventory calculations, monitoring, charts, and one notebook that runs the whole thing.
I made the models compete
The M5 retail forecasting competition got me interested in LightGBM, which featured prominently among its successful approaches. But I wanted to see how it compared with alternatives, so I put three models through the same experiment.
Seasonal naive starts with “next week will probably look like last week.” AutoARIMA looks for statistical patterns in sales over time. LightGBM learns across products and locations, using sales history, prices, and calendar information. Each has to predict the next four weeks.
My evaluation harness rewinds the calendar to 18 different starting points. At each one, the models see only the sales history available then, and their predictions are checked against what happened next. The harness checks dates and forecast outputs before scoring them, compares the models on the same data, and saves the predictions for inspection.
LightGBM won on the synthetic demo, with 5.9% order-cycle forecast error, compared with 6.8% for AutoARIMA and 12.0% for seasonal naive. These are results from the demo, not the M5 competition.
Okay, but what do we order?
A forecast doesn’t know what’s already sitting on the shelf. The ordering logic combines predicted demand with available stock, delivery time, a safety buffer, and minimum order quantities to recommend a purchase. That gives the model’s output a practical use beyond making a nice chart.
There’s also monitoring for deteriorating accuracy, consistent over- or under-prediction, and uncertainty ranges that deserve suspicion. LightGBM supplied a good example. Its supposedly 80% prediction range caught actual sales only 67.7% of the time. I’d want that calibrated before trusting it with purchasing decisions, even though it won the comparison.
How I got through it in a week
I used LoopGate, my own Python development harness, to work with coding agents while automating formatting, linting, complexity checks, type checking, security scanning, and tests with a 100% coverage threshold. It checks the software, while the separate evaluation harness checks how the forecasting models perform.
Having those checks running gave me more room to learn the domain and work through the decisions. The public demo uses synthetic data and explicit inventory assumptions, so there’s more validation to do before real deployment. For a week’s work, though, I’m pleased that you can follow it from the input data right through to an order recommendation.