Inspiration
I kept noticing a contradiction that was hard to ignore: restaurants and bakeries can throw away food that is still good at the end of the day, while people only a few miles away may be worried about their next meal. Seeing usable food treated like trash while families and neighbors struggle with food access made me feel that there had to be a better way. That food was made with someone’s time, water, energy, and care—it should have a chance to help someone instead of becoming waste.
As I learned more, I realized that one part of the problem is coordination. A restaurant may have a small amount of surplus food near closing, but may not know who can accept it quickly. A nonprofit may be able to use the food, but may not know it is available. And even if both are ready, someone still has to handle the pickup. I built RescueRoute Fremont to explore a simple handoff: connect a donor, a compatible recipient, and a volunteer driver before edible surplus becomes waste.
What it does
RescueRoute is a Fremont-focused prototype with three views: Donor, Nonprofit, and Volunteer. Donors type what is left over in plain language, such as “we have 14 veggie wraps, keep them cold, pickup before 8:45 PM,” and a rule-based demo parser turns that into an editable donation listing.
Recipient organizations see available food ranked by a transparent demo fit score based on food type, storage, diet, capacity, and simulated distance. The app shows the factors behind each score so the recommendation is not a black box. A volunteer then accepts a simulated local route, confirms pickup and delivery, and the prototype dashboard updates pounds rescued, items rescued, completed deliveries, and a clearly labeled rough CO₂e demo estimate.
RescueRoute is not a live food-recovery network. Its organizations, availability, routes, and impact totals are fictional demo data.
How we built it
I built RescueRoute with Next.js, React, TypeScript, Tailwind CSS, and Vercel. The technical core is a rule-based parser that turns informal donor text into editable donation details—quantity, food type, storage needs, dietary/allergen tags, and pickup deadline—without making up missing information.
I also built a transparent heuristic scoring function that ranks fictional recipient organizations using food type, storage, diet, capacity, and simulated distance. It explains the factors behind each recommendation instead of presenting a black-box result.
The app uses browser-local persistence so the demo state remains available after refresh. I also used deterministic initial state followed by post-mount restoration to prevent a server/client hydration mismatch in Next.js. This kept the donor → recipient → volunteer workflow reliable during the live demo.
Challenges we ran into
The parser was the hard part. Restaurant staff don't write spec sheets, they write 'some extra wraps from catering, maybe 14, they have cheese.' Getting quantities, allergens, and deadlines out of that reliably without inventing data took a lot of edge-case handling. I also had to be careful about honesty: the demo data is fictional, the parser is rule-based rather than real AI, and I didn't want the app to ever imply it guarantees food safety or legal compliance. Every one of those limits is labeled in the UI.
Accomplishments that we're proud of
I built a complete donor → recipient → volunteer workflow that can be demonstrated from posting through confirmed delivery. The prototype updates its impact totals only after a delivery is completed, and its transparent demo fit score explains the factors behind each recommendation instead of relying on a black box. I also designed the donor flow so a restaurant worker can create a structured surplus-food listing in about one minute.
What we learned
I learned that the boring parts are the important parts: pickup deadlines, storage requirements, allergen lists. A beautiful app that gets those wrong is useless for real food rescue. I also learned how much thought goes into making demo software honest: labeling fictional data, refusing to invent pickup times, and being upfront about what's rule-based versus what's real.
What's next for RescueRoute
The next step is community validation. I am reaching out to Fremont-area food-distribution organizations to learn what information, storage capacity, operating hours, pickup workflows, and food-safety requirements would make a real tool useful rather than burdensome.
A future partner-led version could explore approved organization accounts, shared persistence, private driver coordination, and optional urgent alerts. Any real-world version would need food-recovery partners, clear food-safety procedures, privacy protections, and appropriate volunteer-management practices before handling real donations.
California’s SB 1383 sets statewide edible-food recovery goals and creates recordkeeping requirements for qualifying commercial food generators and participating food-recovery organizations. RescueRoute does not claim to make businesses compliant; it explores how clear donation details and handoff records could support a more organized workflow.
Longer term, I'm exploring an agentic layer on top of this workflow. Today every handoff is manual: a donor posts, a nonprofit browses, a volunteer accepts. A coordinator agent could watch new surplus postings, match them against recipient profiles and driver availability, and propose the full donor → recipient → driver handoff in one step — escalating to a human whenever confidence is low or a food-safety flag appears. The rule-based parser and transparent fit score stay as the trustworthy core; the agent handles the coordination busywork around them. That only makes sense with real partners and real data, which is why community validation comes first.
Built With
- css
- html
- javascript
- next.js
- node.js
- react
- tailwind
- typescript
- vercel
Log in or sign up for Devpost to join the conversation.