PantryShare: Community Food Rescue Platform

One line: Turn surplus food from schools and homes into meals for neighbors in need, with real‑time matching, maps, and logistics built in.

Repo: https://github.com/dhrumilp12/LionHack-PantryShare Folders:

  • Frontend PWA: PantryShare/
  • Backend API: Backend/

Inspiration

Every day, school cafeterias toss perfectly good food; extra trays, produce near “best by,” or unopened packaged items; because there isn’t an easy, trusted way to route those items quickly to someone who could use them. As high‑schoolers, we see this waste up close. PantryShare was inspired by a simple question: “What if students and schools could list surplus in seconds, and volunteers nearby could claim it just as easily?” That’s how PantryShare was born: a social‑good platform to reduce waste and feed our community.


What It Does

PantryShare connects three groups in a tight loop:

  • Listers (students, households, cafeterias) quickly post surplus items with a photo, quantity, expiry, and pickup window.
  • Volunteers discover nearby items on a live map, tap to view details, and “Claim Pickup.”
  • Optional Admins at shelters confirm receipt and update needs, ensuring donations go where they help most.

Core flows:

  • Surplus Listing: guided mobile form with photo upload.
  • Live Map: geolocated pins for “Available” items, sorted by distance.
  • Matching & Claims: nearest‑neighbor suggestions and a one‑tap claim flow.
  • In‑App Messaging: lister and volunteer coordinate pickup logistics.
  • Impact Dashboard: shows total meals rescued and estimated CO₂ emissions avoided.

How We Built It

  • Frontend (PWA): Vue.js + Tailwind CSS, mobile‑first, installable as a PWA for quick access. Google Maps JS API powers pins and geolocation. Socket.IO (or Firebase Cloud Messaging) drives real‑time notifications and chat.
  • Backend: Node.js + Express REST API with Socket.IO for messaging. JWT‑based auth and role‑based access (Lister, Volunteer, Admin).
  • Database: Firebase Firestore stores users, listings, chats, and aggregate metrics.

Repository structure:

  • PantryShare/ — Vue.js PWA, map views, listing forms, chat UI, and dashboard.
  • Backend/ — Express API routes (/auth, /listings, /chat, /dashboard), Haversine matching service, and Firestore adapters.

Key model (Listing document):

{
  "id": "uuid",
  "ownerId": "user_uuid",
  "photoUrl": "https://…",
  "description": "8 slices of whole‑wheat bread",
  "quantity": 8,
  "expiryDate": "2025-08-05T18:00:00Z",
  "pickupWindow": {
    "start": "2025-08-05T15:00:00Z",
    "end":   "2025-08-05T17:00:00Z"
  },
  "location": { "lat": 40.7128, "lng": -74.0060 },
  "status": "Available"   // "Claimed", "Delivered"
}

Representative endpoints:

  • POST /api/auth/signup and /api/auth/login
  • GET /api/listings (available listings)
  • POST /api/listings (create listing)
  • PUT /api/listings/:id/claim (volunteer claim)
  • POST /api/chat/:listingId (send message)
  • GET /api/dashboard/stats (impact metrics)

System sketch:

Frontend PWA (Vue, PWA, Maps, Socket.IO)
        ⇅ HTTPS + WebSockets
Backend API (Express, JWT, Socket.IO)
        ⇅
Firestore (users, listings, chats, metrics)

The Tech That Made It Work

  • Vue.js + Vite + Tailwind CSS (PWA)
  • Google Maps JavaScript API
  • Node.js + Express + Socket.IO
  • Firebase: Firestore + (optional) Cloud Messaging
  • Auth: JWT, bcrypt for password hashing
  • Hosting: Netlify/Vercel (frontend), Render/Heroku (backend)

The Math and the Matching

  • Nearest‑Neighbor Matching (Haversine distance):

For two points with latitude/longitude in radians: $$ d = 2R \arcsin!\Bigg(\sqrt{\sin^2!\Big(\frac{\Delta\varphi}{2}\Big) + \cos(\varphi_1)\cos(\varphi_2)\sin^2!\Big(\frac{\Delta\lambda}{2}\Big)}\Bigg) $$ where $R \approx 6371 \text{ km}$.

We filter by pickup window overlap, then sort candidates by distance.

  • Impact Estimates:

Meals rescued: $$ \text{Meals} = \sum_i \frac{\text{quantity}_i}{\text{portion_size}} $$

CO₂ avoided (rule‑of‑thumb): $$ \text{CO₂}_\text{saved} \approx \text{Meals} \times 2.5 \text{ kg CO₂e} $$

These are displayed in the dashboard to make impact visible and motivating.


Challenges We Ran Into

  • Real‑Time Coordination: Synchronizing listing claims to avoid double‑booking required careful server‑side checks and atomic updates.
  • Geospatial Accuracy: Handling edge cases for user geolocation (permissions, fallback), rate‑limiting map updates, and keeping pins fresh.
  • PWA Offline Caching: Ensuring cached views remain useful while avoiding stale data in critical flows like claiming.
  • Notifications: Balancing browser permission prompts with good UX; integrating FCM securely with environment keys.
  • Security and Roles: Designing a simple role system (Lister/Volunteer/Admin) while keeping endpoints least‑privileged and JWTs short‑lived.

Accomplishments We’re Proud Of

  • A complete end‑to‑end rescue flow: list → map → claim → chat → delivered.
  • Clean, mobile‑first UX that’s fast on real phones.
  • Real‑time updates for claims and chat that feel instant.
  • A tangible impact dashboard; numbers that tell a story.

What We Learned

  • Designing for constraints (pickup windows, perishability) changes data modeling and UX details.
  • Firestore indexing and batched writes are essential for smooth feeds and safe claims.
  • Small touches (smart defaults, distance sorting, photo hints) significantly increase completion rates.
  • Building trust matters: clear statuses, confirmations, and transparent metrics help users feel confident.

What’s Next

  • Admin Mode: Shelter confirmations, needs calendars, and “open slots” to pull donations proactively.
  • Scheduling & Routing: Multi‑stop pickups and time‑window optimization.
  • Trust & Safety: Basic reputation system, issue reporting, and verified orgs.
  • Accessibility & i18n: WCAG improvements and multilingual support.
  • Impact Fidelity: Better CO₂ modeling per food type and standard portion size settings.

How It Meets Judging Criteria

  • Completion: Demonstrable listing, map discovery, claim flow, chat, and basic metrics.
  • Originality: Hyper‑local school/community focus on food rescue with student volunteers.
  • Complexity: Combines PWA, real‑time messaging, geospatial matching, and role‑based flows.
  • Purpose: Reduces waste and fights hunger with measurable outcomes.
  • User Experience: Simple, map‑centric mobile design optimized for “few taps to claim.”

Demo Plan

1) List a Meal: Create a listing with photo, quantity, and pickup window.
2) Map & Claim: Volunteer finds the closest pin and claims it.
3) Coordinate: In‑app chat confirms timing and drop‑off.
4) Deliver & Record: Status updates to “Delivered,” dashboard metrics increment.

If you’re judging, we recommend starting on the map, tapping a pin, and walking through a claim to see the real‑time pieces in action.


Acknowledgements

Thanks to the Stratford Preparatory Hackathon Club and the LionHacks team for the prompt and community focus—and to every volunteer who makes surplus food a shared resource, not waste.

Built With

Share this project:

Updates