Inspiration
Picture a pantry opening tomorrow. It has rice and canned food, but very little produce. A nearby pantry has produce it could share. Someone still has to find that mismatch, protect each pantry's own stock, arrange a handoff and check what actually arrived.
That last step matters. A promise of food does not fill a shelf.
Food Bank of Iowa's FY2025 impact report describes a network of 700 partners and programs across 55 counties. That scale led us to ask whether a simple shared workflow could help participating pantries rebalance approved food between replenishment deliveries. Source
Pantry Relay starts with a pantry's next service, protects the sender's own stock, and follows a transfer through to what the receiver actually accepted. The problem hypothesis comes from public research. We have not claimed pantry interviews, partnerships or field results.
What it does
Pantry Relay helps an approved network coordinate food already available at its participating sites.
- Record a pantry's next-service category need and another pantry's available lot, including a protected local reserve.
- Review explained transfer proposals that check quantity, urgency, use-by cutoffs, storage, capacity, restrictions and approximate distance.
- Reserve stock and receiving capacity, then record acceptance, pickup and arrival.
- Enter the actual accepted weight. A short or damaged delivery requires an exception reason and leaves unmet demand visible. Food confirmed after a service deadline receives no fulfillment credit for that missed service.
- Review receipt totals and export the audit trail.
In our fictional demo, Cedar Grove sends 120 pounds of produce to Eastside. Only 112 pounds are accepted. Pantry Relay counts 112 pounds received, records the 8-pound exception and leaves that gap visible. Received pounds are not a claim about meals served or people fed.
Accounts, separate networks and administrator, coordinator and driver roles support the workflow. Registered networks start empty. Demo workspaces are labeled and separate. No household identities are needed.
How we built it
React and TypeScript provide the interface. Python and FastAPI handle the workflow. SQLite supports local self-hosting. The public deployment uses PostgreSQL on Cloud SQL, Firebase Hosting and Cloud Run.
The planner is deterministic and explainable. It checks constraints, prioritizes near-term needs and use-by cutoffs, and allocates available quantities without proposing the same stock twice within a plan. Distances are clearly labeled straight-line estimates. A person confirms the actual trip.
Transactional reservations, version checks and explicit transfer transitions protect against stale data and duplicate actions. Stock leaves the source at pickup. Accepted food enters the destination with its full quantity protected from immediate redistribution. Cancellation releases reservations. A failed delivery never restores missing stock or counts it as received.
Passwords are hashed, sessions use secure cookies, changes require CSRF protection, and the server enforces permissions and network boundaries. No paid AI or mapping API is required to operate the app.
We verified 129 backend tests across SQLite and PostgreSQL, with five storage-specific skips. All 24 Chromium browser scenarios passed locally and on the Firebase app. WebKit passed the original 22 scenarios plus two added short-desktop regressions locally and hosted. Firefox passed the 22-scenario baseline in Linux CI. A signed-in session and reserved transfer survived a forced server revision replacement. Automated accessibility checks found zero WCAG 2.1 A/AA violations across 24 reviewed views and states. These are engineering checks, not field validation or certification.
Shivam Gupta directed the project, its priorities and quality requirements. AI tools assisted extensively with research, implementation, testing and documentation. The demo uses synthetic narration, not a recording of Shivam's voice.
Challenges we ran into
The hardest part was defining a successful transfer. A match is too early to count impact. A delivery can still hide damaged or missing food. We made custody, partial acceptance and outstanding demand explicit.
We also needed a focused problem. MealConnect, Food Rescue Hero and pantry management platforms already handle important parts of donation and operations. Pantry Relay focuses on next-service pantry shortages, protected surplus and receipt evidence. External inventory integrations are future work.
Food restrictions and physical handling remain operator responsibilities. Restricted lots are excluded from matching. Accepting cold food requires temperature and condition records within configured limits. A full rejection can record zero accepted weight without inventing a temperature. The app supports an organization's procedures and does not certify food safety.
Accomplishments that we're proud of
- One connected workflow from a category need to a persisted, auditable receipt.
- Protected local stock so helping another pantry does not quietly deplete the sender's own service.
- Partial-delivery and failed-delivery paths that preserve inconvenient differences.
- Explained suggestions and useful feedback when no transfer is feasible.
- A polished public app with accounts, permissions and an isolated demo that needs no API keys.
What we learned
Trust depends on modest claims and reliable records. Moving food is not the same as preventing waste. A promising workflow is not validated demand.
Commercial viability starts with the operator. We propose a six-week supervised pilot, followed by a $149 per network per month pricing experiment for up to 10 sites. At an illustrative coordinator cost of $25 per hour, that price needs about six hours saved monthly to break even on labor alone. Neither the savings nor willingness to pay has been established. Free MIT-licensed self-hosting remains available. There is no per-pound fee or payment flow in the app.
What's next for your project
Start with one willing coordinator, three nearby pantries and existing transport. Establish a baseline, use approved stock, then measure category gaps, staff time, accepted weight, exceptions and entry burden. Ask a real budget holder whether the results justify continuing.
Before real operation, the network must confirm transfer permissions, receiving windows, food-handling procedures and account recovery ownership. Operator tools can reset passwords and revoke sessions. Self-service email recovery, offline synchronization, road-route optimization and inventory integrations are future work.
The next milestone is a useful supervised pilot with honest results. If the workflow creates more work than it saves, we will change it with the people who operate it.
Try the app | Watch the captioned demo | Source and verification | Testing instructions
Log in or sign up for Devpost to join the conversation.