Food Surplus
DOD/IITR
2025
The gap between surplus and hunger
Redesigning Food Redistribution as Coordination Infrastructure for India
Context
ServDes 2025 · Delhi, India
My role
Product Design Lead
Method
Research-led, guideline-driven
Outcome
27 stakeholder interviews. 34 field observations. 3 prototype sessions. A four-sided service system that makes food redistribution the rational choice for every actor in the chain simultaneously.
Role & constraints
My role
{Product Design Lead}: Research, Synthesis, Service Blueprint, UX Strategy
Team
{4 members}: Designers, researchers
Timeline
6 weeks
Constraints
No existing platform to evaluate or iterate on.
Four radically different user types with conflicting schedules, literacy levels, digital access, and motivations.
India has no food donation liability protection law.
Context & the problem
What is this?
My first brief was "reduce food waste." The fieldwork showed that framing was too blunt: it pulled the work toward awareness campaigns and donation drives instead of the coordination and incentive failures that made redistribution fragile in the first place.
Challenge
Surplus food exists within 5–10km of hungry people in every major Indian city. The gap between them is not distance, not volume, not willingness, it is the complete absence of a real-time, trusted, liability-protected coordination mechanism that makes redistribution the rational choice for every actor simultaneously.
The numbers behind the opportunity
FAO / FSSAI 2023
68M
Tonnes of food waste generated in India annually — among the world's highest by volume
GHI 2022
#107
India's Global Hunger Index rank out of 121 nations — despite being one of the world's largest food producers
Urban surveys 2020–22
80%
migrant workers in major Indian cities face food insecurity
Outlook Traveller
700kg
average food waste per wedding. With zero systematic redistribution channel. Generated multiple times daily
Stakeholder interviews, n=12
15–25%
Wedding caterer overproduction: deliberate, because running short is a social catastrophe
Ministry of Labour 2021
40M
Internal migrants whose food access collapsed entirely during COVID-19
Before designing, I needed to know if this was worth solving at scale. The opportunity is larger than the immediate problem suggests.
~2,400
Weddings happen in Delhi every month. At 700kg surplus per event and a 60% capture rate with this platform, that's ~1,000 tonnes of redirectable food monthly — in one city.
Addressable Surplus (Delhi alone)
3.8M
Estimated migrant and informal workers in Delhi. Our pilot targets 0.5% in year one — 19,000 people — as a proof point before city-scale expansion.
Potential Beneficiaries (Delhi)
1 report
The missing layer is documentation. If donors can automatically generate a defensible handover record and impact summary, donation becomes easier to justify operationally and commercially.
Donor Incentive
1 law
India lacks a Good Samaritan Food Donation Act. Our pilot data is the evidence base to advocate for it, which would unlock every restaurant, hotel, and caterer in India as a potential donor.
Policy Leverage Point
Field research
This is what we knew going in
I ran three parallel research tracks over six weeks. Secondary research framed the scale of the problem, primary interviews surfaced incentives, and field observation exposed the constraints that actually changed the product.
Weather
Monsoon kills the system for 3 months
Distribution hotspots under flyovers and open sites become inaccessible June–August. Any system without seasonal routing logic fails for a quarter of the year. We designed weather-aware hotspot flagging into the NGO dashboard.
Signal
Dark store zones have connectivity dead spots
Three Blinkit stores we scouted had intermittent 4G indoors. The driver app must work offline for handover logging, syncing when connectivity restores. This isn't a nice-to-have — it's a hard requirement.
Timing
Wedding surplus spikes happen at 11PM–1AM
Most events end late. The food is available at midnight but NGO volunteers aren't. Dark store transit solves this — food drops at midnight, NGO collects and distributes at 7AM breakfast run. The time gap is a feature, not a bug.
Mobility
Worker settlements shift with construction projects
A camp of 800 workers exists for 14 months, then moves 6km. Static distribution hotspots don't work. The SevaSpot map needs a "temporary site" tag with automatic expiry — otherwise NGOs are distributing to empty lots.
Language
Instructions in Hindi still fail for 40% of workers
Workers come from Bihar, Odisha, UP, Jharkhand — different mother tongues. The distribution volunteer can't read Odia. The beneficiary card must be icon-only at critical points. Colour-coded meal labelling (green/orange) is the signal that works universally.
Power
Dark stores have power backup; labour camps don't
Power cuts at labour camps average 3–4 hours daily in summer. Any beneficiary flow requiring phone charging or mobile internet at the point of distribution will fail regularly. Physical e-Shram card QR — not an app on a phone — is the right beneficiary verification mechanism.
“
“We have 40 kilos of biryani right here. I'd give it away in a heartbeat. But if one person gets sick and points to me, I lose everything I've built in 15 years. Who's protecting me? Nobody. So it goes in the bin.”
Wedding caterer owner · Karol Bagh, Delhi · Field interview
“
“I can organise food for 300 people if I know the delivery is at 7PM. Tell me it's coming sometime between 5 and 10, and I can't plan anything. My volunteers leave. People wait. I look incompetent. The food arrives and there's no one left to give it to.”
NGO field coordinator · Dilli Bhojan Sewa · Field interview
“
“I would not stand in that line. Not because I am not hungry — because everyone would see me. My family thinks I am doing well here. That line says otherwise.”
Wedding caterer owner · Karol Bagh, Delhi · Field interview
What these three quotes told me
The barriers are liability, predictability, and dignity. Every design decision in this project flows from those three words. A solution that solves only logistics fails at the first caterer interview. Any system that solves all three simultaneously becomes self-sustaining.
Insight synthesis
What each actor is actually trying to do
Jobs-to-be-done told me why they hire something and why they fire it. I mapped what each actor currently fires (their workaround) and what they'd hire FoodFlow to do instead. The gaps between those two states are exactly where the product lives.
Donor · Wedding Caterer / Restaurant
When I have surplus food at event end, help me dispose of it in a way that protects my business — without adding any work to my closing team.
Currently fires
Throws food away — fast, low-effort, zero accountability
WhatsApp-calls a known NGO contact — slow, unreliable, ties up staff
Core anxieties
One sick beneficiary = front-page story = 15 years of brand gone
FSSAI inspector finds improperly handled donations
Donation process taking longer than closing the venue
NGO · Field Coordinator
"When I'm running distribution, tell me what food is coming, when, and in what quantity — so I can deploy the right volunteers and not fail the people waiting."
Currently fires
WhatsApp coordination across 6 donor contacts simultaneously
Excel spreadsheet updated manually after each run
Core anxieties
200 workers arrive and food is 3 hours late
No freshness metadata — how old is this food?
No impact data to show grant funders
Delivery Partner · Driver
"When I accept a pickup, show me exactly what I'm collecting — weight, containers needed, pickup window — so I can plan my day and not get stuck at the site."
Currently fires
Swiggy / Zomato — predictable tasks, clear pay, known workflow
Considers this "charity work," not real income
Core anxieties
Arriving and finding 80kg with no containers provided
Onboarding paperwork he can't read (literacy barrier)
Unclear whether this run pays or is "volunteer"
Beneficiary · Migrant Worker
"When I'm near a distribution point, give me food that's familiar and hygienic — served in a way that doesn't make me look like a charity case in front of my coworkers."
Currently fires
Street vendors — ₹30–50, no stigma, familiar, fast
Goes without eating on low-income days
Core anxieties
Being seen in a public "charity queue" — social stigma is real
Food that looks or smells like "leftovers"
Inconsistent schedule — shows up, nothing there
Driving synthesis
Every actor in this system wants to participate. What's missing isn't motivation — it's a trusted mechanism. FoodFlow's job is not to persuade anyone of anything. It's to eliminate the specific friction that makes doing nothing the rational default. For caterers: liability coverage. For NGOs: timing predictability. For drivers: task clarity. For workers: dignity. Four different frictions. One system design. The product succeeds when redistribution becomes the path of least resistance simultaneously for all four actors.
Defining the direction
Principles for digital transformation
Self-serving options
Principle 1
Upfront options for direct access to required resources without having the need to reach out customer service.
Guided communication
Information clarification
Information Prioritization
Principle 2
Building channels to reduce information overload with gateways for efficient visual and content focused de-clutter.
Ensuring personalization
Approachble and communicative
Evolutionary guidance
Principle 3
Guiding members through the experience with ease and proactive communication when needed.
Guided communication
Prioritizaing member needs and actions
Client-driven customizations
Principle 4
Providing options for customization to ensure employer and employee engagement.
Approachable and communicative
Inclusive and communicative
Real-time updates & feedback
Principle 5
Plan content as well as recommendations based on real-time member behavior and landscape.
Ensuring personalization
Inclusive and communicative
Cohesive wellness
Principle 6
Ensuring mental health-focused proactive and dynamic digital experience through multiple channels.
Prioritizing member needs and actions
Approachable and communicative
System Architecture & Key Decisions
FoodFlow is a four-sided service with a physical logistics layer. The most important work was not drawing a straight donor-to-beneficiary line; it was defining the operational surfaces in the middle where reliability either holds or breaks.
System boundary decision
FoodFlow's scope: from the moment surplus food is identified → to the moment it reaches a beneficiary. Approximately a 3–8 hour window. We explicitly do not address upstream overproduction (a supply chain problem requiring different policy levers) or downstream nutrition tracking (a public health system problem). Doing one thing reliably beats doing three things poorly.
Full system flow by actor
Actor
→
Donor
Logs food: dish, quantity, cook time, allergen. Gets FSSAI cert preview. Confirms pickup.
Receives driver ETA + handover checklist. Liability transfers on driver acceptance.
Matches food to nearest dark store by proximity + capacity. Assigns driver from available pool.
Accepts run. Reviews food card: emoji icons, kg weight, utensil count, pickup window.
Navigates to pickup. Collects food. Confirms handover in app. Drops at dark store.
Monitors live map. Flags anomalies (late driver, over-capacity store).
Updates distribution route from NGO demand heatmap.
Reviews daily pipeline. Exports government compliance report.
Auto-generated CSR report + impact card: who was fed, where, when.
Run closed. Earnings confirmed.
Updates next-day capacity. Reviews demand heatmap.
Optional verbal feedback to volunteer.
Sees branded van at known SevaSpot. Presents e-Shram QR. Receives sealed, labelled meal pack.
Distributes at SevaSpot. Marks distributed. Logs headcount.
Volunteer inspects at dark store. Portions, labels veg/non-veg, seals packs. Updates app.
Receives early intent signal (2hr advance). Updates available capacity by food type.
Admin
Driver
NGO
Beneficiary
Surplus Logged
Pickup Assigned
Dark Store Transit
Quality Check
Distribution
Data Close
Key decisions and what I rejected
The most important part of any design log is what you didn't build. These were the eight decisions that defined the system's character.
Chosen
Route all food through dark stores (Blinkit / Zepto)
Zero new infrastructure. Existing cold chain. 24/7 availability. B2B partnership gives dark stores CSR credit and marginal revenue for idle capacity. It is the strongest operational lever in the concept, but still needs live pilot validation before it can be treated as a proven model.
Rejected
Build dedicated refrigerated food bank warehouses
High capex. Long setup. Creates dependency on a single organisation. Every NGO we interviewed cited failed food bank attempts due to real estate costs and operational complexity. The problem is coordination, not storage. Building storage solves the wrong layer.
Chosen
e-Shram + Aadhaar QR for beneficiary verification
400M+ migrant workers already carry e-Shram cards. No new registration. QR scan reuses public infrastructure many workers already know while also generating cleaner evidence for service and policy conversations.
Rejected
New FoodFlow beneficiary registration system
Creates friction. Creates a data silo. Excludes the most vulnerable — field observation showed workers are deeply sceptical of new registration schemes, sometimes fearing documentation implications. Meet them where they already are.
Chosen
Auto-generate FSSAI certificate at handover — no form
68% of caterers cite liability as their #1 barrier. The certificate is generated from the food logging step — no additional input. Compliance must be invisible and automatic. The moment of transfer is the moment liability moves — and that must feel like a button tap, not a legal procedure.
Rejected
Manual food safety declaration per donation
Prototype testing showed caterers abandoned the flow at the form stage. Any friction in the donation step sends food to the bin. Three early sessions were enough to justify simplifying the handover step immediately.
Chosen
Icon + quantity cues as primary language for the driver app
A clear food-type icon plus quantity and container count lands faster than a paragraph in any single language. Field research identified delivery partners who could not reliably parse English food names, so this became an accessibility requirement rather than a stylistic choice.
Rejected
Text-only food specifications for drivers
One prototype session exposed the risk immediately: a driver accepted a run without noticing the "5 large containers required" note in text. He arrived without containers, and the handoff broke down. We moved to an icon-primary card right after that session.
Chosen
Reject flow is a first-class action — zero friction, zero penalty
If rejecting feels costly, drivers will accept runs they can't execute, then ghost. Ghost rates destroy NGO planning. Honest rejection is more valuable than false acceptance. Reject is the same visual weight as accept — optional reason, no warning message.
Rejected
Penalise rejections with lower run priority
Counterintuitively creates worse outcomes. Drivers who feel penalised game the system. Ghost rates increase. The run still fails — but later, when an NGO has already deployed volunteers. Penalising rejection doesn't reduce it. It just hides it until it's too late to recover.
Decision we're still uncertain about
Dark store routing vs. direct caterer-to-NGO delivery
Dark store adds a step to the chain. The argument for it: cold storage, quality control, neutral handover point that decouples caterer timing from NGO scheduling. The argument against: every added node is a failure point. We would validate this in Phase 1 with an A/B test — direct route vs. dark store route — measuring spoilage rate and NGO distribution reliability as the deciding metrics. We don't have ground truth yet. Naming that uncertainty explicitly is more honest than defending a guess.
Failure modes I designed against
Good systems designers think adversarially. I mapped every realistic failure scenario and the design decision that guards against it.
Failure mode
Driver ghosting post-acceptance
NGO deploys volunteers; food never arrives; 200 workers leave hungry
Volunteer arrives to drop food; no space; food sits in van and spoils
NGO rejects food at quality check; donor disputes; system gridlock
Distribution site inaccessible; beneficiaries don't know alternative
NGO distributes to empty lot; food wasted; driver run wasted
Acquisition cost paid; no long-term value; volunteer effort wasted
SevaSpot operating; workers nearby but won't approach
2-step acceptance window (accept → confirm at pickup location via GPS ping). NGO notified instantly on no-show. Admin can re-assign in under 5 minutes.
Admin capacity dashboard shows real-time fill % per dark store. Assignment algorithm blocks routing to stores above 80% capacity. Manual override requires admin PIN.
Cook-time timestamp is entered at logging (not estimated) and locked. Quality dispute triggers a 10-minute admin review with photos. Decision is recorded and visible to both parties.
SevaSpot map has "weather-sensitive" flag. Alternate indoor sites pre-mapped per zone. Seasonal routing switches automatically June–September.
SevaSpot "Temporary Site" tag with 90-day expiry. Auto-archives and prompts re-verification. NGO can flag site as inactive instantly.
End-of-first-run impact notification is personalised and hyperlocal ("43 workers, 2.4km away"). Research shows first-impact visibility is the highest-leverage retention moment. Target: see the face before the second ask.
Distribution branded as "SevaSpot" (service, not charity). Volunteers in uniforms, not vests with "DONATION" written on them. Sealed, labelled meal packs. Queue design mimics dhaba counter. No signage referencing hunger or donation at the distribution point itself.
Dark store over-capacity
Food freshness dispute
Monsoon kills outdoor SevaSpots
Worker camp relocates
Donor drops out after 1 run
Beneficiary stigma prevents uptake
How it manifests
Design guard
Where FoodFlow sits in the landscape
Model
Robin Hood Army
App + WhatsApp
Phone-based
None
None
None
External vendors
Dark store network
None
Partial
Auto FSSAI cert
Partial
None
CSR-dependent
Volunteer-limited
Any QC-covered city
Global pilots only
Manual
Strong
Manual
Basic
Minimal
Live + exportable
AI dispatch
4-sided real-time app
Feeding India (Zomato)
No Food Waste
EatCloud (global)
FoodFlow
Coordination
Cold Chain
Liability Cover
Real-Time Data
Scalability
Validation plan, metrics & policy
How I would test whether the concept deserves to scale.
Because the project stopped at concept and early prototype validation, this section focuses on success metrics, pilot sequencing, and the policy evidence the service would need to generate.
Evidence note
This project stopped at concept and early prototype validation. This section therefore focuses on the success metrics, pilot sequencing, and guardrails I would use to decide whether the system deserves to scale, not on shipped business results.
North star
Captures the full system in one number
Primary
What we optimise weekly
Secondary
Growth and system health indicators
Guardrails
Hard stops — if crossed, we pause
Meals successfully distributed per active donor / week
If donors churn, it drops. If NGO distribution fails, it drops. If drivers ghost, it drops. This metric can only be healthy if every part of the chain works. It forces cross-functional thinking from every team member.
Donor 30-day retention %
Driver pickup acceptance rate
Food-to-distribution time (hours)
NGO supply prediction accuracy (±30 min)
Food spoilage rate % of total handled
New donors onboarded / month
Dark store utilisation rate (off-peak hours)
CSR reports generated (institutional stickiness)
Repeat SevaSpot zones identified
Cities where model replicates (QC coverage as proxy)
Food safety incident rate > 0
Any beneficiary complaint re: dignity at distribution
Driver earnings below Swiggy / Zomato equivalent per hour
Any donor exposed to FSSAI liability despite platform
What we deliberately did not track
We chose not to use "total meals served" as our primary metric — even though it's the most instinctive one. Optimising for volume creates incentives to accept lower-quality food, cut quality checks, and over-index on high-volume easy sites while ignoring hard-to-reach communities. A reliable 200-meal daily run at one site is worth more than a 400-meal spike that happens three days a week. Reliability is the product. Our north star metric punishes inconsistency automatically.
India needs a Good Samaritan Food Donation Act.
This platform solves the coordination layer. Only legislation can solve the liability layer at scale. India's current legal framework has no equivalent of the US Bill Emerson Good Samaritan Food Donation Act (1996) which grants blanket civil and criminal liability protection to donors acting in good faith. Without that protection, every caterer in India who wants to donate faces real legal exposure. FoodFlow's pilot data is the evidence base for that policy change. The app collects the data. The data demonstrates the system works safely. The demonstrated safety makes the policy argument. The policy makes every restaurant, hotel, and caterer in India a potential donor — permanently, without a platform to coordinate them.
This is what a systems-level design intervention looks like: the product is not the endpoint. The product is the proof that the endpoint is possible.
© 2026 Prabhav Singh • All rights reserved