Forecasting, Pricing & Replenishment Engine

Forecasting is only valuable when it improves a decision. I built this system to give operational teams a reliable answer to the questions that determine commercial outcomes: how much will we sell, what will it sell for, what is a prospective brand worth, and how much inventory should we buy?

It replaced three separate legacy pipelines with one production codebase, shared data foundation, and self-service interface. The system serves 22 active accounts and gives business users access to forecast products without asking them to understand models, code, or warehouse tables.

Four Decisions, Four Purpose-Built Products

The system does not assume one generic model can solve every forecasting problem. Each product is designed around a distinct business decision, time horizon, and user.

• Demand forecasting estimates units sold over one to 90 days for operations and replenishment teams.
• Price forecasting estimates where a SKU’s selling price is likely to land for pricing and finance teams.
• Opportunity sizing estimates prospective revenue for a brand at a given price point, supporting business-development decisions.
• Replenishment recommendations translate demand, uncertainty, and inventory velocity into a weekly buying decision, including how long an order is likely to last.

The Right Model Has to Earn Its Place

Product behavior varies radically. Some SKUs sell daily; others move in unpredictable bursts. Some have enough history for machine-learning models; others require statistical methods designed for intermittent demand.

Rather than declare one “best” model, the engine runs candidate models through a shared rolling backtest harness and selects the champion empirically. Routing can vary by account and by SKU. Forecasts include low, middle, and high ranges, so teams can plan around uncertainty instead of treating a point estimate as a promise.

The system also detects stockouts and corrects for the fact that zero sales may mean there was no inventory—not that demand disappeared. Seasonal behavior, price effects, traffic, conversion, and inventory velocity are made available through a shared feature foundation.

Built as a Production System, Not a Notebook

The model layer sits on a governed data platform built with BigQuery and dbt. Output contracts keep forecast tables consistent for downstream applications. Automated jobs build features, run forecasts, evaluate performance, and publish results. The user-facing application and API are deployed as authenticated services, so account teams can explore forecasts, run scenarios, and download reports without relying on an analyst.

The result is a decision system that can improve over time: data improvements benefit every product; new models compete against the current champion; and the interface gives operators a practical way to use the work.

Tech Stack

Python, BigQuery, dbt, FastAPI, Next.js, Docker, EKS, Kestra, and a backtesting and champion-selection framework built for multi-account forecasting.