Probabilistic forecasting · Supply chain client

Demand Forecasting & Inventory Decision Engine

Most inventory planning still happens in a spreadsheet, using a single-number forecast and a safety stock rule of thumb. This platform replaces both: it forecasts demand as a distribution, then converts that distribution into concrete restocking and safety-stock decisions under a target service level.

The problem

A point forecast cannot answer the question planners actually ask. “How much will we sell” is less useful than “how much do we need on hand so that we only run out 5% of the time, given this lead time”. The second question requires the shape of the distribution, not its mean.

Stockouts cost sales and customer trust; excess inventory ties up capital and warehouse space. The gap between those two failure modes is exactly where quantiles live.

What I built

Forecasting

  • A multi-model pipeline that fits and compares Temporal Fusion Transformer, Chronos, LSTM and Holt-Winters per series, so classical baselines stay in the running — on short or sparse series they frequently win.
  • Quantile regression for uncertainty, producing a demand distribution rather than a single trajectory.
  • Decision logic that turns quantiles into lead-time-aware safety stock and restocking quantities under a configurable service level.
  • Forecast health monitoring, so a model that silently degrades is visible before planners act on it.

Application

  • FastAPI backend with background worker management for long-running training and inference jobs.
  • React / TypeScript / Chakra UI frontend: interactive forecast charts, quantile tuning, decision scenario tables and health dashboards.
  • Docker Compose deployment with PostgreSQL, Traefik and a BI tool integration for reporting outside the app.

Outcome

Deployed to production for client operations. A weekly manual planning process estimated at four or more hours now runs unattended across more than 300 SKUs, and planners spend their time on exceptions and scenario comparison instead of spreadsheet maintenance.

On the infrastructure side, switching the backend to CPU-only inference dependencies cut 1.5 GB from the Docker image — a measured reduction that materially improved deploy times on the client's hardware.

Stack

Note: this case study is deliberately written without client names, product names or customer data. SKU counts and the image-size reduction are logged; the weekly time saving is the client's own estimate of the process it replaced.