Ingredient-Level Demand Forecasting for a Meal-Kit Company's Weekly Menus
Let's Connect
Overview
What we built
A meal-kit company was ordering ingredients for 10 fulfilment hubs on educated guesswork, wasting perishables on one side and scrambling for substitutions on the other. We replaced the guesswork with ingredient-level forecasts.
In plain terms: every week the company publishes a new menu, and subscribers pick their recipes. But ingredient orders had to be committed two weeks before anyone knew what subscribers would choose, and those commitments were made in planner spreadsheets using experience and instinct. Guess high and fresh food expired in the warehouse; guess low and hubs ran short, forcing last-minute recipe substitutions that upset subscribers and cost the company credits.
We built a forecasting platform that predicts, hub by hub, which recipes subscribers will pick, based on what is on the menu, what each subscriber has liked before, the season, and how people have swapped meals in the past. The system turns those predictions into recommended purchase orders and updates them nightly as choices lock in, leaving planners to review only the exceptions it flags. Perishable waste fell 23% across all 10 hubs within two quarters, forecast error dropped from 31% to 14%, substitutions fell 41% year on year, and planning time per menu cycle went from 3 days to under 1.
The Problem
Weekly menus, guessed demand
The weekly menu is the heart of a meal-kit business, and it was also the heart of the problem. Each new menu reset demand in ways nobody could measure in advance: a returning favourite, an unfamiliar cuisine, a seasonal dish, all shifted what subscribers would pick. Yet ingredient orders across 10 fulfilment hubs had to be committed two weeks ahead, long before subscriber choices came in.
Planners bridged that gap with spreadsheets and experience, estimating recipe popularity from memory of similar dishes. Some weeks they were close. Other weeks a recipe outperformed or flopped, and the errors flowed straight into the physical world: pallets of over-ordered perishables ageing towards write-off in one hub, while another ran out and substituted ingredients into recipes subscribers had specifically chosen.
The substitutions were the most corrosive part. A subscriber who ordered one meal and received an altered version had a reason to complain, and the company answered complaints with credits. Waste drained margin quietly; substitutions drained it loudly, one disappointed subscriber at a time, while planners lost 3 days of every weekly cycle to the spreadsheet grind.
Two-week blind window
Ingredient orders were committed two weeks before subscribers made their choices, so every purchase was a bet placed before the race began.
Popularity guessed from memory
Recipe demand was estimated from planner experience with similar dishes, an approach that broke whenever a menu introduced something genuinely new.
Perishables becoming waste
Over-ordered fresh ingredients had nowhere to go, expiring in hubs and turning forecasting error directly into food waste and lost margin.
Substitutions and credits
Under-ordering forced last-minute recipe substitutions, and every altered box generated complaints and credit payouts that compounded the original forecasting miss.
What it was costing them
Every forecasting miss was paid for twice. Over-ordering turned fresh ingredients into waste across 10 hubs, while under-ordering turned into substitutions, complaints and credit payouts. Planners spent 3 days of each weekly cycle producing estimates the business could not fully trust, and with recipe-level forecast error at 31%, the company was carrying the cost of uncertainty in every purchase order it signed.
The Solution
Ingredient-level forecasting engine
We built the platform around a simple chain: predict what subscribers will pick, translate that into ingredients, and turn ingredients into purchase-order recommendations per supplier and hub. Recipe selection models learn from menu attributes, each subscriber's preference history, seasonality and past swap behaviour, so a new dish is forecast from its characteristics rather than a planner's best analogy to something served before.
Timing was as important as accuracy. Forecasts re-run nightly as subscribers lock in their weekly choices, so predictions tighten steadily as real orders replace estimates ahead of the commitment deadline. By the time orders must be placed, the platform has already reconciled its early view with actual subscriber behaviour, hub by hub, rather than freezing a guess two weeks out.
We deliberately kept planners in charge. The platform recommends purchase orders; planners review a dashboard that surfaces only flagged exceptions, cases where the forecast is unusual or confidence is low. Routine lines flow through without ceremony, which is how a weekly cycle that consumed 3 days of planning effort compressed to under 1.
Key decisions
Forecast at ingredient level
Predictions roll from recipe selections down to individual ingredients per supplier and hub, because purchase orders are written in ingredients, not recipes.
Model each hub separately
Every hub gets its own forecast, so purchase-order recommendations reflect what that hub's subscribers actually choose rather than a network-wide average that fits nobody.
Learn from swap behaviour
Past meal swaps are treated as demand signal, revealing which recipes subscribers avoid or trade towards when a menu gives them the choice.
Review exceptions, not everything
Planners review only forecasts the platform flags as unusual, keeping human judgement where it adds value and out of routine lines.
Re-forecast every night
Predictions refresh nightly as subscribers lock in weekly choices, so the final purchase orders are shaped by real selections, not stale estimates.
Measurable Impact
What changed after launch
The operational gains showed up within two quarters: perishable ingredient waste fell 23% across all 10 hubs, and recipe-level forecast error at the moment of order commitment dropped from 31% to 14% in weighted absolute percentage terms. Buying against a trustworthy forecast meant hubs stocked closer to what subscribers actually chose, week after week.
Subscribers felt the difference through what stopped happening: last-minute ingredient substitutions fell 41% year on year, and with them the credit payouts the company had been issuing as apologies. Planners now spend under 1 day per weekly menu cycle instead of 3, reviewing exceptions rather than building every estimate by hand, and the network absorbs new menus without the old scramble.
Forecast accuracy
Recipe-level error at 31% at commitment
Error down to 14% at commitment
Perishable waste
Routine over-ordering expiring in hubs
Waste down 23% across all 10 hubs
Subscriber experience
Frequent substitutions, complaints and credits
Substitutions down 41% year on year
Planning effort
3 days of spreadsheets per menu cycle
Under 1 day reviewing flagged exceptions
Headline results
Perishable ingredient waste reduced by 23% across all 10 hubs within two quarters
Recipe-level forecast error at order commitment fell from 31% to 14% (weighted absolute percentage error)
Last-minute ingredient substitutions down 41% year on year, cutting subscriber credit payouts
Planner time per weekly menu cycle cut from 3 days to under 1 across the network
Tech & Tools Used
What powered the build
Every tool below earned its place in this engagement. Here is the part each one played.
Python
The core language of the forecasting platform, covering the feature pipelines over subscriber history, the demand models themselves and the purchase-order recommendation logic.
LightGBM
Gradient-boosted models predict per-hub recipe selections from menu attributes, preference history and seasonality, handling the mix of categorical and behavioural features cleanly.
scikit-learn
Provides the preprocessing and evaluation backbone: encoding menu features, running backtests and measuring forecast error so model improvements are proven before they reach production.
Apache Airflow
Runs the nightly re-forecast cycle, refreshing predictions and purchase-order recommendations as subscribers lock in their weekly choices across the network.
dbt
Models subscriber, menu and order data into tested transformation layers, giving the forecasts and dashboards one consistent definition of every metric.
Snowflake
The analytics warehouse holding order history, menu attributes and swap behaviour at the scale the demand models train on each cycle.
PostgreSQL
Operational store for generated forecasts, purchase-order recommendations and exception flags, serving the planner dashboard and the downstream ordering workflows.
React
The planner-facing dashboard where flagged exceptions are reviewed, forecasts are compared against commitments and purchase-order recommendations are approved or adjusted.
Grafana
Monitors pipeline health and forecast quality over time, alerting the team when data feeds stall or model error starts drifting upward.
Ready to Build your Food & Meal-Kit E-Commerce Business with Predictive Modeling & Forecasting
Ask Byte
Ask Byte
Typically replies instantly
just Now
Hi! I'm OrganByte's assistant. How can I help you today?
AI-generated content may be incorrect
