How a large steel wholesaler went from “fluffy AI vision” to a steel-price model people actually use

The vision

The company is a large steel wholesaler: it buys, stores and sells steel products, mostly to big industries such as automotive and construction rather than to individual buyers. Software isn't part of its core business, so the project started from a standing position, not a platform.

The problem the desk brought was specific. Steel prices are highly volatile, there are many products, and delivery times are long, so the margin comes from buying when prices are low and selling when they are high. Some buying decisions feel risky enough that the desk holds off, or moves too late. What they wanted was not a system that makes the call, but an extra tool: something that, when a buyer is already leaning toward a risky purchase, can add the confidence to go ahead. Get even a handful of those calls right a year and it pays for itself.

The long-term vision was a predictive model across around 30 products. They started far smaller: a proof of concept on a short list, with minimal data preparation, to test whether the core problem was solvable at all. The first workshop ran eight hours. Andrea, the data scientist who would go on to build the thing, was deliberately left out of it, and the room was kept small.

The frustrations

Then the data scientist enters, with six weeks and, importantly, dedicated time to think rather than an afternoon every Friday for half a year. Andrea is upfront about her own scepticism: “I'm going to predict future prices; if I could do that I would not even be working.”

The data-science reality was not the dream case:

• The series don't suit classic ARIMA-style time-series models, and the team wanted to bring in many external factors.
• Stakeholders wanted an interpretable model, not a black box, and there wasn't enough data to justify a black box anyway.
• Real test data was scarce, which makes overfitting hard to rule out.
• Many candidate models assume independent data points, and it wasn't clear that held.
• A model is only valid over the range of data it was trained on. With inflation you routinely need predictions at price levels the model has never seen, and the training window included the COVID-era disruption on top of that.

Her rule of thumb from past projects: the moment you start wanting to exclude an inconvenient stretch of data so the models look better, “it never ends good.”

The pivot that made it work

Instead of fighting the regression problem, they changed the question. In the continuous stakeholder meetings, Andrea asked whether there was a percentage move that actually mattered to the business. There was, so they turned it into classification: four classes (heavy rise, rise, drop and heavy drop), defined by whether the price moved more than a set percentage over a given number of months.

That one change fixed the evaluation problem. The model was now trained for a defined event, and the team could see how much data stood behind each class. Classification also changed what the features should be: raw price levels mattered less than direction, so they built trend features, scaled them deliberately so that interactions between them meant what the team intended, and did heavy feature selection because the interpretable models could only take a handful of inputs.

After that work, three of eight products were predicting well. The question shifted from “is the model wrong?” to “is the information even in this data?” They added two more data sources, ran the same method, and got six of eight products showing promising results, all within the six weeks.

Selling it to people who don't do ML

The next hard part was a 30-minute presentation to the company's top management, an audience that has seen plenty of slides with good accuracy numbers that then didn't work in practice. Andrea's approach: assume the room is highly intelligent, explain exactly how the accuracy figure is calculated, and be honest that because the models were chosen for performance on a short test window, only time will show how well they hold up. Then talk about the risks and the running costs openly, because management is weighing potential income against expense, and “people buy what they understand, especially in troubled times.”

What they built, and what actually mattered

The deployment plan was rough but concrete: internal and external data sources feeding around 30 models, with predictions surfaced in an interactive dashboard. Under that sits a fairly standard stack: API integration, a storage and compute platform, a raw landing area, a data-engineering pipeline to clean the data, an ML platform to train and store models, and a prediction store wired to the dashboard. No exotic sensors, no extreme data volumes, so the team knew it was feasible.

The insight Andrea keeps returning to is about priorities. The customer's priority is good predictions. They don't care whether the raw-to-clean pipeline is the most elegant code ever written, at least until the predictions are good and people rely on the product, at which point they very much care that bad input data never breaks it. For a small company that can't afford repeated failed attempts, you prioritise accordingly and get the important parts right the first time.

From there: a minimum-viable-product phase to let time pass and check the models stayed relevant, automate the data flows, and map competencies honestly rather than trying to be a one-person “unicorn” covering every skill. Then a phase with a small group of users to get them comfortable, and gradual scale-up to more products, with the end-to-end flow tuned for low maintenance.

Two checkpoints stood out. After four months, the models were tested on genuinely new data and held up. A few months later, a buyer who had decided a purchase was too risky checked the model, saw it judged the move worthwhile, and went ahead. That single decision, Andrea says, “paid off 13% of the total project cost at that time.”

Keeping it working is its own discipline: a champion model alongside challengers, watching whether a different model or new features have become more predictive as the economy moves, and retraining on a schedule. Andrea calls it “a whole new type of thinking.”

Why the shape of the output matters

One theme carries to any desk buying a volatile commodity, whatever model sits underneath. A single predicted price is the wrong thing to hand a buyer, because it hides the uncertainty. The wholesaler's answer was to stop predicting the number and start predicting the move that mattered: will the price rise or fall by more than a threshold the business cares about, over a defined window. That is a claim you can check against what actually happened.

The same logic points at calibration. If a model says “30%”, that should happen close to 30% of the time across many such calls. And, as Andrea notes, when you have only a short test window and you have picked the models that did well on it, the honest position is that you need time and out-of-sample results to know how they adapt. A visible, walk-forward track record is how a desk sees that for itself instead of taking a slide on trust.

Bringing the same idea to the strategic purchaser

MetalAlert is that approach as a subscription, applied to metal markets rather than steel. For each metal it tracks, it estimates the probability that the average price over a future month runs at least 2%, 5% or 10% above or below the current month's average, over one- and three-month horizons. It is decision support, not a decision-maker. When the odds cross a threshold you set, or jump week over week, it emails you, and each model's walk-forward track record is shown per metal so you can judge how calibrated it has actually been.