Resilient Food — Our Story
What Inspired Us
The question that started everything wasn't technical. It was human:
Why do people starve in disasters when food is often nearby?
We kept coming back to a single, uncomfortable truth — the problem is rarely absolute scarcity. It's invisible connectivity. Local vendors have stock. Smallholder farmers have pledged crops. Community organizations have trust networks built over decades. But when a hurricane hits Port-au-Prince or a flood sweeps through eastern DRC, none of that local capacity is mapped, activated, or connected to the people who need it most.
International aid convoys arrive 72 hours later with the wrong food, routed through broken infrastructure, disconnected from the cultural and logistical reality on the ground. Meanwhile, a vendor three kilometers away has rice and knows every family on the block.
That gap — between local capacity that exists and coordination that doesn't — is what inspired Resilient Food.
How We Built It
We designed Resilient Food around a three-phase model that mirrors how communities actually experience disaster:
Before Disaster — Build the Map
We couldn't wait for a crisis to figure out who has food. So we built tools to register vendors, enroll farmers, and record crop pledges ahead of time. The geospatial layer ingests HOT OpenStreetMap road shapefiles and flags underserved communities using road-network distance — not straight-line distance — to every market node.
During Disaster — Activate the Network
When USGS earthquake feeds or OpenWeatherMap alert thresholds are crossed, an automated Twilio SMS blast fires to every registered vendor in the affected region — in seconds, not hours. NGOs can also trigger manual activations with severity levels. The Market Pulse module, powered by Google Gemini, ingests real-time vendor-reported messages and generates AI summaries of price shocks and shortages for NGO planners.
After Disaster — Close the Loop
Digital ration tickets are issued to households and redeemed at local vendors, keeping economic activity inside the community. Every donor contribution flows through Solana Devnet with an on-chain transaction receipt — because in humanitarian contexts, transparency isn't optional.
What We Learned
The biggest technical surprise: straight-line distance is a lie.
When we first visualized underserved communities on a flat map, many appeared close to markets. Once we ran the road-network graph, communities that looked 4 km away were actually 18 km by any passable road — a distinction that is life-or-death in a post-earthquake landscape.
We also learned that building for four distinct user roles simultaneously — general_public_donor, un_donor, ngo_volunteer, and vendor — meant every design decision had to work at radically different levels of technical literacy and institutional context. A UN donor and a street vendor in Port-au-Prince are both users of the same system. That tension made us better designers.
Challenges We Faced
The geospatial pipeline was very vast. Ingesting HOT OSM road shapefiles, cleaning topology, snapping origin/destination coordinates to the road graph, and handling fallbacks when the graph was unavailable consumed most of Day 1. GeoPandas, Shapely, Fiona, and momepy each had their own quirks — and getting them to agree on a coordinate reference system was its own battle.
Blockchain integration Solana Devnet behaves differently under load, and Phantom wallet adapter edge cases are not well-documented. We scoped to devnet-only, which was the right call — but it required rethinking how we communicated "real enough to matter" to judges and users.
Scope discipline was hard. The problem space is enormous. We could have built only the map, or only the ration system, or only the donation flow. The challenge was building all of it in a way that felt coherent — where each module reinforced the others rather than just coexisting. The three-phase before/during/after frame is what held it together.
Resilient Food is not a finished product. It is a proof that local food systems can be the first responders — if we give them the tools to be.
Built With
- apscheduler
- atlas
- fastapi
- gemini
- geopandas
- hdx-pipeline
- javascript
- mongodb
- openweathermap
- pandas
- pydantic
- pymongo
- python
- react
- tailwind
- twilio
- usgs-earthquake-feeds
- uvicorn
- vite
Log in or sign up for Devpost to join the conversation.