Good food.
Better routes.
Zero waste.
We match bakery surplus with nearby food pantries—and give volunteer drivers the smartest route to get it there fresh.
0 neighbors
ready to drive this week
One app. A meaningful trip.
Driver participation happens in the BakedBoston mobile app, so you can choose a route when it fits your day.
Create your driver profile.
A secure check that takes about two minutes.
Select a nearby order now, or reserve one for a preferred route and time.
Drive to the bakery and collect the food.
Bring it to the pantry and complete the delivery.
the BakedBoston appDriver routes are mobile-only. Tap or scan to open the App Store.
From surplus
to supper.
A simple act, coordinated intelligently.
Edible food is often discarded because a bakery cannot move it in the narrow window when it is still fresh—at the same time that local food-access organizations are under growing pressure. BakedBoston coordinates the people, places, and timing needed to turn that gap into a reliable delivery.
Bakeries post surplus
Pickup timing, confirmation status, and access details are added in under a minute.
We optimize the match
The MIP enforces complete route timing, protects expected completed pickups, then balances pantry reach and priority, raw and distributed food, equity, direct CO₂e benefit, and driver fit.
Neighbors drive the loop
Volunteers claim a route and deliver food while it’s still fresh.
Less waste is
a solvable problem.
At each rolling decision epoch, BakedBoston uses a Gurobi mixed-integer model to choose jointly among complete, feasible driver–bakery–pantry plans. Each route column includes a just-in-time departure, five minutes to load at the bakery, the trip to the pantry, and five minutes to unload. The formulation is a research-informed academic prototype: operational constraints are explicit, while volunteer acceptance remains a transparent synthetic assumption until real participation data exists.
The feasible assignment x maximizes one acceptance-adjusted network feature vector ψ: pantry reach, raw and ultimately distributed food, evenness, opportunity priority, direct environmental benefit, and driver fit.
Among driver d's feasible routes ℛ(d), choose the route with the largest completion likelihood πᵣ times completed-impact value ωᵀφᵣ. There is no separate participation stage or 99%-of-best cutoff.
A route that is unlikely to happen earns less expected-impact credit, but a small difference in a synthetic probability cannot automatically veto a route that rescues substantially more food or produces a fairer, cleaner result.
mᵣ is drive time; wᵣ and sᵣ are normalized requested-time and requested-area misses. This is an auditable scenario assumption—not a trained behavioral model.
Bakery-unusable food follows that bakery's landfill/pig-farm/compost mix. Pantry-undistributed food follows that pantry's unique landfill/pig-farm mix; pantry compost is zero.
ω = (10, 10, 10, 10, 10, 10, 20, 20)ᵀ. Every component in φᵣ is normalized to [0,1] before the policy weight is applied, and route contributions are adjusted by πᵣ. Hard feasibility is enforced first, so an attractive score can never override a closed window or missed deadline.
A binary variable: 1 when complete timed route r is selected, otherwise 0.
A synthetic probability based on driving burden and driver time/location fit. It scales impact instead of serving as a hard preliminary objective.
Modeled completion credit for available unique pantry identities, capped once per pantry.
Acceptance-weighted raw bakery-food volume plus evenness calculated from cumulative expected raw donations.
Acceptance-weighted ultimately distributed food, where hᵣ = qᵣ · ηᵦ · δₚ, plus cumulative expected saved-food evenness.
A pantry available but less often served receives more acceptance-adjusted credit through its smoothed recent-opportunity history.
The acceptance-weighted bakery no-pickup result minus bakery-unusable waste, pantry-undistributed waste, and usable-cargo tonne-kilometre transportation emissions, min–max normalized across candidates.
Acceptance-weighted fit: one minus the mean normalized drive-time, requested-window, and requested-area burdens.
Login time is the decision epoch, not a forced departure. The model schedules the latest feasible departure, so planned lead time at the origin is not penalized.
Confirmed partner windows, bakery pickup deadlines, pantry latest arrivals, full travel and service timing, at most one route per driver request, and at most one assignment per bakery pickup.
All requests entering the same decision epoch are optimized jointly. Each request, physical driver, and bakery pickup can appear in at most one selected assignment; an open pantry may receive multiple deliveries.
Conflict-free options are allocated by rank: maximize how many drivers receive recommendation #1 before allocating recommendation #2, then optimize route utility within each layer.
Requested time and ZIP areas influence utility and modeled acceptance. A route may fall outside them and still be recommended when it is feasible and comparatively strong.
The formulation adapts established problem families rather than claiming a new one from scratch. The exact BakedBoston weights, simulated schedules, and acceptance coefficients are original prototype choices and are not estimates reported by these papers.
- Rolling-horizon joint decision epochs
- Complete timed route-column generation
- Hard pickup, receiving, and service feasibility
- One acceptance-adjusted expected-impact objective
- Opportunity-based pantry priority and cumulative food equity
- Direct waste-pathway and transport CO₂e accounting
- Conflict-free, coverage-first driver route menus
- Soft requested-time and ZIP-area matching
Follow the current routing logic in seven auditable steps.
The walkthrough requires the current registered and validated partner network. Partner identities and coordinates come from the live database; the driver request, food realization, and decision epoch are synthetic and read-only. This explanatory trace applies the current route accounting and acceptance-adjusted expected-impact selection without creating an offer; the production service solves simultaneous requests jointly with Gurobi.
Loading the current bakery and pantry network…
No fictional organizations are substituted. The current Neon database quota must be restored before this database-backed demonstration can populate.