Seasonal Buy Optimizer
Decides how many units to buy of a product purchased only once per season: neither too few nor too many.
The problem
Deciding how much to buy of a product that is never restocked was pure individual judgment: buy too little and you run out, buy too much and you are left with unsold stock.
What I did
I defined the method for deciding how much to buy and turned it into a nine-step statistical pipeline: deseasonalization, best-week selection, inverse normal or Student's t depending on sample size, configurable service levels and re-seasonalization, with a 0–100 reliability score per SKU. For products with no history, solved cold-start with CLIP visual embeddings over Qdrant.
The outcome
In production, in the buying team's hands. The project also set the engineering and security standard for the rest of the ecosystem.
How it sizes the buy
- Sales history per SKUInput
- DeseasonalizationStrip the season effect
- Best-weeks selectionRepresentative demand
- Inverse normal or Student's tBy sample size
- Service level & re-seasonalizationHow much stockout risk to accept
- Suggested lot & reliability scoreOutput
The product is bought once per season: there is no replenishment to correct a mistake. That's why the pipeline picks the distribution by sample size and ships, alongside the number, how much confidence it deserves.
Stack
- Python
- Streamlit
- SciPy
- SQL Server
- CLIP
- Qdrant
- LangChain
- GPT-4o
- Docker
Blue Star Group internal project — the code is not public.
Next project: FOB Cost Predictor →