Inspiration

In mid June, I had just gotten my hair cut in my town's center, and was waiting for my sister to come and pick me up. To pass time, I walked into a bakery called Bakey - I had been there before but never in the evening. It was 5:30pm and the place closed at 6pm, advertising daily fresh-baked goods all over the windows and menus. I asked the woman behind the counter what would happen to the countless pastries and breads inside of the display cases if everything would be baked again tomorrow, and to my surprise she told me that it all gets thrown away every day! BakedBoston was inspired by a clear mismatch I saw in my community: bakeries often end the day with high-quality leftover food, while neighborhood food pantries are under growing pressure to serve more people with limited resources. The problem is not only food waste. It is timing, coordination, and logistics.

Surplus food is highly perishable. Pantries have different receiving windows. Volunteer drivers have limited time and transportation flexibility. I wanted to build something that could make those moving pieces work together in a practical, community-centered way.

I was also inspired by the idea that operations research should not stay in textbooks. I majored in Operations Research at Rice University, and throughout my education implemented Gurobi, Matlab, and Excel countless times in a variety of hypothetical scenarios. This hackathon inspired me to address a problem I observed by using optimization to create a social-impact tool that accounts for the real constraints and demands of the community.

What it does

BakedBoston is a logistics platform that connects participating bakeries, food pantries, volunteer drivers, and BakedBoston administrators through a shared system.

  • Bakeries can post confirmed pickup windows for leftover food.
  • Pantries can manage receiving schedules, including recurring and one-time windows, and specify whether deliveries are attended or unattended.
  • Drivers can open the mobile app to browse nearby delivery opportunities or search for routes that fit their schedule, origin, and preferred destination.
  • Administrators can oversee organizations, schedules, onboarding, reports, route activity, and maps.

At the core of the system is an optimization engine that evaluates feasible bakery-to-pantry routes and recommends the strongest matches based on timing feasibility, pantry priority, travel time, waiting time, and route fit.

The platform also manages:

  • route reservations
  • live delivery tracking
  • confirmation flows
  • proof-of-delivery photos
  • partner onboarding
  • notifications and operational updates

How we built it

I built BakedBoston as a full working prototype with both web and mobile interfaces.

Web platform

The web platform includes:

  • a public-facing website explaining the mission, the app, and the optimization model
  • a hidden administrator portal for managing bakeries, pantries, routes, maps, onboarding, reports, and data exports
  • bakery partner workspaces
  • pantry partner workspaces

Mobile platform

The mobile app includes:

  • driver onboarding and route browsing
  • bakery partner access
  • pantry partner access
  • delivery tracking
  • confirmations
  • proof-of-delivery workflows
  • push-style operational notifications

Optimization layer

I built a separate optimization repository focused on the operations research component. The current recommendation engine:

  1. pulls eligible bakery pickups and pantry receiving windows
  2. generates feasible bakery-to-pantry route candidates
  3. propagates route timing from departure through pickup and drop-off
  4. filters out infeasible routes
  5. scores the remaining routes using pantry priority, drive time, waiting time, and destination preference
  6. returns ranked recommendations to the live product

The scoring logic can be summarized as:

$$\text{score}_r = w_p \cdot \text{priority}_r - w_t \cdot \text{driveMinutes}_r - w_w \cdot \text{waitingMinutes}_r - w_d \cdot \text{destinationMinutes}_r$$

where each feasible route 'r' is rewarded for serving higher-priority pantries and penalized for longer driving, more waiting, and worse fit with the driver's preferred destination. In plain language, the model balances urgency, efficiency, and route fit.

Pantry priority is designed to reflect relative need without ever excluding a pantry from consideration. Instead of removing pantries that have recently received deliveries, BakedBoston lowers their priority score slightly and continues to keep them eligible for matching.

In the current prototype, pantry priority is based on how often a pantry has recently received deliveries. Pantries that have received fewer recent deliveries receive a higher priority score, while pantries that have already received more are still considered but receive a lower score. This allows the optimizer to balance fairness and feasibility: a nearby pantry that has recently received food can still be selected if it is the best feasible option, but the system gently favors pantries that have been served less often.

In simplified form, the prototype calculates pantry priority as:

priority = 1 / (1 + recent deliveries)

This means:

  • a pantry with fewer recent deliveries receives a higher priority value
  • a pantry is never excluded just because it has already received food
  • the model balances urgency with timing and travel feasibility rather than treating priority as the only objective

In plain language, the model balances urgency, efficiency, and route fit.

Operational features

We also built:

  • Google-based address validation and geocoding workflows
  • private APIs that feed live bakery, pantry, and route data into the optimizer
  • attended vs. unattended pantry logic
  • route cancellation and confirmation handling
  • photo-based delivery verification
  • admin-side onboarding and communications tools
  • a visual optimization demo showing how a successful route is chosen

Challenges we ran into

One major challenge was that this is a timing-sensitive logistics system that relies on the accuracy of schedules and availability. Every action affects other users.

For example:

  • a bakery can only provide one pickup per window
  • a pantry may receive multiple deliveries
  • some pantries are staffed, while others are unattended
  • drivers may want either immediate routes or future reserved routes
  • some bakeries may not have food every day

That meant I had to build much more than a simple matching interface. I had to think carefully about:

  • recurring schedules
  • one-time overrides
  • reservation timing
  • confirmation deadlines
  • cancellation logic
  • proof-of-delivery flows
  • delivery status updates across multiple user types

And most importantly, adjusting the optimization engine to account for changes in these schedules so that it can still provide the most effective routing options for all parties involved.

I also spent a great deal of time refining the user experience across:

  • web
  • mobile portrait mode
  • mobile landscape mode
  • administrator, bakery, pantry, and driver roles

Accomplishments that I am proud of

I am proud that BakedBoston is a functioning system with real workflows. I have never published an app before, and I am excited to onboard real bakeries and pantries in my community.

Some accomplishments we are especially proud of:

  • building a public website, a live mobile app, and multiple partner/admin portals
  • publishing the app to the App Store
  • creating a working optimization engine for matching bakery pickups to pantry drop-offs
  • designing a full operational flow for both reserved and spontaneous deliveries
  • supporting attended and unattended pantry delivery handling
  • building strong onboarding flows for bakeries and pantries
  • creating maps, reports, exports, and admin oversight tools
  • building a visual optimization demo to explain route selection
  • turning a community food-waste idea into a real logistics product

What I learned

I learned that social-impact logistics problems are full of hidden complexity. Moving food efficiently is not only about finding the shortest path, it is about coordinating uncertainty, timing, fairness, and human behavior. People are more likely to volunteer their time to drive, or volunteer surplus food, if the constraints of their schedule and availability can be conveniently accounted for.

I also learned how important interface design is when the product involves many different stakeholders. A bakery, a pantry, a volunteer driver, and an administrator each need different information, different controls, and different levels of urgency.

From the optimization side, I learned that it is powerful to begin with a transparent, explainable model before expanding into more advanced large-scale assignment formulations. I also learned that a strong prototype requires not just a good model, but strong operational logic around confirmations, notifications, exceptions, and edge cases.

What's next for BakedBoston

Next, I want to move BakedBoston from prototype to pilot.

Our next steps include:

  • onboarding real bakeries and food pantries across Boston
  • recruiting a larger volunteer driver base
  • collecting live delivery data to improve route recommendations
  • expanding the optimization model into a richer multi-driver assignment framework
  • incorporating driver behavior and acceptance patterns into future route suggestions
  • building stronger analytics around pantry coverage, food recovered, and unmet demand
  • refining delivery verification, communications, and support workflows
  • growing BakedBoston into a sustainable citywide food redistribution network

Long term, I see BakedBoston as both a practical community platform and a scalable logistics model for reducing food waste and improving food access in cities beyond Boston. I plan to hand over control of the platform to the Boston Food Pantry if the pilot is successful.

Built With

Share this project:

Updates

Submission history