Continuous Replenishment Engine
Projects how much of each product will sell and suggests how much to buy: neither running out nor piling up stock.
The problem
Buyers decided repurchases with hand-made spreadsheets and macros, across hundreds of products: constant risk of running out or piling up stock.
What I did
Created the engine's baseline: deseasonalized projection from the most representative weeks of the history, seasonal factor, how much stock is needed ahead, per-product suggested action with traffic lights and Excel export with photos and conditional formatting.
The outcome
In production, in the buying team's hands: it replaced the spreadsheet-and-macro process.
How it suggests the buy
- Sales history per SKUInput
- Deseasonalized projectionOver the most representative weeks
- Seasonal factorReapplied to the projection
- How much stock is neededFor the months ahead
- Suggested action per productWith a traffic light
- Excel export with photosOutput
The product is replenished, so an error corrects itself next cycle — at the cost of a stockout or overstock. The engine separates signal from seasonality, reapplies it over the projection, and turns the result into an action per product, not a loose number.
Stack
- Python
- Streamlit
- SQL Server
- Supabase
- openpyxl
- LangChain
- Docker
Blue Star Group internal project — the code is not public.
Next project: Year-over-Year Sales Analytics →