This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle.
What I Built
An unsold croissant has already used butter, flour, energy, and someone's early morning. Baking too little has a cost too: a customer leaves without the thing they came for.
I built SpoilageShield, a daily production planner for independent bakeries. It answers a small, useful question: what should we put in the oven tomorrow?
The owner supplies sales history and product economics. The planner forecasts demand for each product, considers weather and event assumptions, and recommends quantities that fit the bakery's batch sizes and capacities. The result is an exportable morning bake sheet, not another dashboard that leaves the final calculation to the owner.
The first customer I want to serve is an owner-operated bakery with a daily POS export and a handful of repeat products. My pricing hypothesis is ₹999 per location per month. That is a proposed experiment, not a validated price or a claim that anyone has paid.
Food waste is a real problem, but I wanted to avoid turning a global statistic into a promise about one bakery. UNEP's Food Waste Index 2024 estimates 290 million tonnes of food-service waste in 2022. That gives context; it does not tell me how much this prototype will save a customer.
Demo
Video: https://youtu.be/pYO5DtdBd9k
The video walks through the sample workspace, a rainy-day scenario, batch recommendations, evaluation, and the first pilot I would run. The demonstration uses synthetic bakery data throughout. It is a rendered walkthrough of actual model outputs with local synthetic narration.
Code
Repository: https://github.com/Khushi-Sh01/SpoilageShield
The code is MIT licensed. It includes the sample CSV, forecasting engine, browser dashboard, HTTP API, measured backtest, tests, deployment files, and optional provider adapters.
How I Built It
The AI core is scikit-learn, running on the CPU. There is a real random forest for each product. Its inputs are weekday, temperature, rainfall, holiday, and a nearby-event flag. Weather and events are explicit assumptions in this version, not a hidden live data feed.
The history is split in time: earlier training, a later calibration window, and a final untouched holdout. I did not randomly shuffle future bakery days into the training set.
Forecasting alone does not tell a baker how much to make. A unit that goes unsold costs money; a missed sale loses contribution. I use calibration errors to construct demand scenarios, then evaluate feasible batch quantities using:
sales revenue + salvage value − variable production cost
The planner chooses the quantity with the highest mean contribution over those scenarios, subject to product capacity and batch size. It does not guarantee that the bakery will avoid leftovers or sell out at the perfect moment.
One detail changed how I thought about the data: sales are not always demand. If the last loaf sells at noon, the POS export cannot tell us how many people would have bought one after that. The synthetic generator knows full demand, so its labels include that information. Real uploads discard simulated oracle columns and exclude sold-out rows from fitting, calibration, and scoring. That still leaves selection bias; better availability logging and a censored-demand model belong in the next version.
What the benchmark actually showed
On the final 29 synthetic days, across 145 product-days, the random forest achieved 6.11 units MAE, compared with 8.12 for a weekday baseline. That is 24.8% lower MAE in this simulation, with 8.31% WAPE.
I also compared the production decisions rather than stopping at a prediction score:
| Synthetic holdout policy | Leftovers | Unmet demand | Contribution, INR |
|---|---|---|---|
| Recorded simulated static bake | 1,777 | 412 | 807,632 |
| Weekday predictor + planner | 745 | 484 | 832,895 |
| Random forest + planner | 830 | 207 | 853,682 |
The forest planner reduced leftover units by 53.3% against the simulated static schedule. It did not beat every policy on waste: the weekday planner left fewer units, while missing more demand. I think showing that trade-off matters more than choosing one flattering percentage.
These are calculated synthetic results, not observed customer savings. The 80% empirical range covered 84.1% of holdout observations; future drift can change that. Recorded weather in the benchmark is also easier than imperfect weather forecasts in a real deployment.
The dashboard evaluates exported scikit-learn trees directly in the browser. I checked Python/JavaScript agreement on 45 prediction and optimization cases, alongside 16 Python tests covering the optimizer, capacity constraints, validation, and HTTP behavior.
Why Does Open Innovation Matter?
The core planning loop does not need an API key, a GPU, or a per-request model bill. After installing dependencies, a bakery can run training and inference on its own machine. Sales data stays in that process unless the owner explicitly enables an external provider.
The model, scenarios, costs, and objective are inspectable. An owner or developer can change the economics, replace the estimator, or audit why the plan changed. I do not have to send a spreadsheet to a language model to decide how many croissants to bake.
There is an optional local Gemma briefing adapter through Ollama. It explains a completed plan; it does not decide quantities. There are also optional TabPFN, MongoDB Atlas, Sentry, and ElevenLabs adapters. They require configuration and live evidence, so I am not describing them as completed sponsor integrations in this submission.
What I Would Test With the First Bakery
I have not run a paid pilot yet. I would start with a 14-day shadow trial: let the baker make the real decision, record what the model would have recommended, and measure leftovers, availability, contribution, and planning time.
The first product milestone is not a subscription button. It is finding out whether the baker trusts the bake sheet, whether their export is usable, and whether the measured value exceeds the time spent maintaining the data.
This build was developed with AI coding assistance from an author-supplied concept. The open-source stack made it possible to replace a simulated forecasting pitch with an implementation whose predictions, costs, and limitations can be checked.
Built With: Python, Streamlit, TabPFN, Tiger Data, PostgreSQL, Plotly, Scikit-learn
Top comments (0)