BakedBoston

Inspiration

BakedBoston was inspired by the disconnect between food waste and food insecurity. Bakeries can have usable surplus food at the end of the day while nearby pantries are struggling to meet demand. The food, the need, and willing volunteers may all exist—but a rescue still fails when pickup windows, pantry availability, travel times, and volunteer schedules do not align.

We wanted to build more than a donation directory. Our goal was to create an operational system that determines which deliveries are feasible, recommends routes volunteers are realistically likely to complete, distributes food fairly among pantries, and verifies that the environmental benefit of rescuing food outweighs the emissions created by transportation.

What it does

BakedBoston connects bakeries, food pantries, and volunteer drivers through a mobile application, partner workspaces, a public website, and a separate optimization service.

Bakeries report available surplus food and pickup windows. Pantries provide receiving availability and operational information. Drivers submit their preferred time, starting area, and optional destination.

The system then:

1. Generates complete driver-to-bakery-to-pantry routes.
2. Calculates departure, pickup, delivery, and completion times.
3. Removes routes that violate bakery deadlines, pantry windows, or the driver’s hard search horizon.
4. Estimates the likelihood that the driver would accept each route.
5. Evaluates food recovery, pantry coverage, distribution fairness, environmental benefit, pantry priority, and driver fit.
6. Uses a Gurobi mixed-integer optimization model to select conflict-free assignments.
7. Turns the selected assignment into a usable reservation, navigation, notification, and delivery workflow.

The public simulator also runs identical synthetic scenarios through BakedBoston and three research-inspired comparison models, allowing users to inspect how different routing strategies affect food recovery, waste, emissions, driving, acceptance, and pantry coverage.

How we built it

The mobile experience was built with Expo and React Native. The website, documentation, partner interfaces, and live simulator use Next.js and React and are deployed through Vercel.

Operational data is stored in Neon Serverless Postgres using Drizzle. The system also integrates Google Maps for travel-time and distance calculations, Vercel Blob for appropriate assets, Expo push notifications, and Resend for email communication.

Optimization is handled by a separately deployed Python service using Gurobi. The application sends a private, authenticated optimization payload containing active driver requests, bakery pickups, pantry opportunities, food quantities, institution parameters, and mapped travel data.

For every feasible route, the optimizer calculates an expected completed-impact score. This combines a transparent acceptance estimate with normalized measures of:

• Pantry coverage
• Raw donation volume
• Raw-donation evenness
• Ultimately distributed food
• Saved-food evenness
• Pantry opportunity priority
• Net direct CO₂e benefit
• Driver fit

The environmental calculation compares the emissions that would occur without pickup against unusable bakery food, undistributed pantry food, and transportation emissions. Bakeries have individual landfill, pig-feed, and compost allocations. Pantries have individual landfill and pig-feed allocations that sum to 100%.

Challenges we ran into

The largest challenge was defining what “best route” should mean. Minimizing distance alone can repeatedly serve the same pantries or recover less food. Maximizing food alone can produce inconvenient routes that volunteers may reject. Maximizing environmental benefit alone can overlook fairness and participation.

We initially treated driver participation too restrictively by keeping only routes extremely close to the highest acceptance probability. That could eliminate valuable alternatives for a single driver. We replaced that approach with one expected-impact objective, allowing a slightly less convenient route to win when its additional food, equity, or environmental benefit justifies the difference.

Environmental accounting was another major challenge. A donation is not automatically environmentally efficient. We had to distinguish total bakery food, usable food, ultimately distributed food, bakery residual waste, pantry residual waste, disposal pathways, and transportation emissions without double-counting benefits.

We also had to translate research models into fair comparison policies. Each comparator needed enough adaptation to accept driver requests and schedule deliveries without giving it objectives or information that the original model did not use.

Finally, connecting a mobile workflow, database, mapping service, production API, optimization service, simulator, and public documentation required careful coordination. A mathematically valid route is not useful unless it can become a reliable recommendation inside the application.

Accomplishments that we’re proud of

We are proud that BakedBoston is a working, end-to-end prototype rather than only a mathematical model or design mockup.

Major accomplishments include:

• Building a functional mobile and web food-rescue platform
• Deploying a separate Python and Gurobi optimization service
• Implementing complete timestamped route generation
• Supporting simultaneous drivers without duplicate bakery assignments
• Creating a transparent acceptance-adjusted objective rather than a hidden ranking rule
• Modeling raw donations separately from ultimately distributed food
• Accounting for bakery waste, pantry waste, disposal pathways, and transportation
• Incorporating pantry coverage and two forms of distribution fairness
• Building a deterministic live simulator with three research-inspired comparison models
• Publishing the methodology, assumptions, institution tables, equations, and research sources
• Creating 57 optimizer tests
• Designing the production system to fail closed when the required solver is unavailable

In the saved five-day seed-2033 scenario, BakedBoston completed 29 deliveries, ultimately saved 316.847 kilograms of food, served all eight available pantries, achieved an expected acceptance rate of 71.6%, and produced 50.139 kilograms of modeled net direct CO₂e benefit. These are synthetic, scenario-relative results rather than field outcomes, but they demonstrate the balance the model was designed to achieve.

What we learned

We learned that routing quality cannot be represented by a single intuitive metric such as distance or food weight. Food rescue is simultaneously a scheduling, assignment, participation, equity, and environmental-accounting problem.

We also learned that feasibility and preference should be treated differently. Bakery deadlines and pantry receiving limits must remain hard constraints. Driver time and geographic preferences are better treated as soft penalties so that the system can still recommend a valuable near-match.

Another important lesson was that transparency improves both the model and the product. Separating external evidence, fixed institution data, seeded simulation values, and unvalidated assumptions made weaknesses easier to identify. It also led us to describe the acceptance sigmoid honestly as a synthetic estimate that should eventually be replaced with observed volunteer behavior.

Finally, the comparison models taught us that specialization naturally wins individual categories. A distance-first model may drive fewer miles, while an environmentally oriented strategy may produce a higher carbon result. BakedBoston’s purpose is not to win every isolated column. Its purpose is to produce the strongest balanced outcome across the factors that determine whether a rescue succeeds in practice.

What’s next for BakedBoston

The next step is a small field pilot with approximately three to five bakeries, two to three pantries, and a volunteer cohort.

The pilot would validate:

• Real bakery surplus and usability distributions
• Pantry receiving and distribution capacity
• Actual bakery and pantry waste pathways
• Volunteer route choices and completion behavior
• Notification and reservation workflows
• The appropriateness of the objective weights
• The accuracy of food and environmental reporting

With informed consent and appropriate privacy controls, actual route-choice data could replace the synthetic acceptance coefficients. Sensitivity analysis could then test whether the model’s weights produce the intended balance among participation, food recovery, fairness, and environmental benefit.

For larger deployments, we plan to cache travel-time matrices, queue optimization epochs, add operational observability, partition requests by geography and time, and integrate directly with partner inventory systems. At regional scale, column generation would allow the optimizer to generate only promising routes instead of enumerating every possible combination.

The long-term goal is to turn BakedBoston into validated, scalable coordination infrastructure for community food rescue—making surplus food easier to share, deliveries easier to complete, and the resulting impact easier to measure and trust.

Built With

• gurobi
• python