When I co-founded Doare.org in 2011, the problem felt straightforward: make it easy for people to donate to nonprofits in Brazil. We built a payment platform, partnered with hundreds of organizations, and somehow grew it into the largest donation platform for nonprofits in Latin America. (Still not entirely sure how that happened.)

What I didn’t expect—and what kept me up at night—was how much of the donation pipeline depended on knowing where the need actually was. A nonprofit could sign up on our platform, but if their outreach didn’t match where the crisis was unfolding, the money just sat there while people went hungry three neighborhoods over. Not exactly the outcome we were going for.

This year made that disconnect impossible to ignore.

Urban Density Breaks the Playbook #

Rural disaster response is hard for obvious reasons—distance, terrain, infrastructure gaps. Urban disaster response is hard for the opposite reasons: too many people, too much infrastructure interdependence, and too many agencies trying to coordinate in the same physical space without running into each other.

COVID-19 hit urban centers in ways that exposed every lazy assumption about disaster relief logistics. In Sao Paulo, the virus didn’t affect neighborhoods uniformly; it followed transportation networks, economic divides, and housing density patterns like it had a map. Relief organizations that planned for city-level response suddenly found themselves needing block-level precision. Most of them weren’t ready for that.

The same pattern played out in New York, Mumbai, Mexico City—pick your dense metropolis. When populations cluster tight, a single overwhelmed hospital or food bank creates cascading failures across a tight geographic area. The need isn’t spread evenly—it clusters, shifts, clusters again somewhere else. Trying to predict it feels like chasing a shadow.

The Coordination Bottleneck #

Here’s what surprised me most during my time at Doare.org, and what I’ve watched play out again in 2020: the technology for mapping crises exists. The technology for distributing aid exists. What doesn’t exist—still, somehow, in 2020—is a reliable way to coordinate between the organizations actually doing the work.

Ushahidi (built originally for Kenya’s 2008 election crisis) provides crowdsourced crisis mapping. Esri’s ArcGIS platform powers geospatial analysis for most government emergency management agencies. Crisis Cleanup handles work order management for disaster volunteers. These tools work well individually. I’ve used them; they do what they promise.

The problem? Relief organization A is on Ushahidi, the city government is locked into Esri, the Red Cross has its own ancient system, and the volunteer coordinator down the street is—I kid you not—using a Google Sheet. Nobody sees the full picture. Duplication of effort isn’t a bug; it’s the default.

Esri published a remarkable statistic earlier this year: their Disaster Response Program received more assistance requests in 120 days of COVID response than in the program’s entire 26-year history. That’s not just volume—it’s a signal that existing coordination channels were overwhelmed and organizations were grabbing whatever tools they could find. Desperation, digitized.

What Marketplace Thinking Gets Right #

These days I manage engineering teams at TaskRabbit. It’s a marketplace that matches people who need tasks done with people who can do them. The parallels to disaster relief coordination are closer than you’d probably think.

Both problems are fundamentally about matching supply (volunteers, resources, expertise) with demand (people in need, specific requirements, geographic constraints). Both have brutal time sensitivity—a Tasker who’s available at 2pm isn’t helpful at 6pm, and food donations that arrive after a shelter closes might as well not exist. Both require trust between parties who don’t know each other and may never meet.

The marketplace model handles these constraints through real-time availability, location-based matching, and reputation systems. Disaster relief coordination could borrow heavily from this approach—the primitives are all there—but most relief platforms are built around organizational hierarchies rather than supply-demand dynamics. Bureaucracy wins over efficiency, again.

Imagine a platform where a shelter posts “we need 50 meals delivered to this address by 5pm” and it flows to the nearest available volunteer kitchen the way a TaskRabbit job flows to the nearest available Tasker. The technology to build this exists; I’ve sketched it out on napkins. The organizational will to adopt it? That’s the harder problem. Always is.

GIS and Crisis Mapping #

The role of GIS—Geographic Information Systems—in 2020 disaster response has been transformative in ways I don’t think the general tech community fully appreciates. Or even knows about, honestly.

When COVID hit, the first useful dashboards weren’t from tech companies—they were from GIS analysts working through the night. Johns Hopkins’ COVID dashboard runs on Esri’s ArcGIS. City governments used the same platform to track hospital capacity, food distribution sites, testing locations. The data layer that made real-time decision-making possible was geospatial. Everything else was just presentation.

For urban disaster response specifically, GIS answers the question that matters most: where? Where are the cases concentrated? Where are the food deserts? Where are the volunteers? Where are the gaps between available resources and actual need? Without that spatial context, you’re just guessing.

Crowdsourced data adds another dimension. Ushahidi’s model—letting affected communities report needs directly via SMS, email, or web—puts information in the system that official channels might miss for days. A family that can’t reach a food bank doesn’t show up in official statistics, but they might text a crisis hotline. If that text becomes a data point on a map, a volunteer can respond. Simple. Effective. Underused.

Smart Infrastructure and Sensor Networks #

Cities with smart infrastructure investments are starting to see payoffs in disaster response. Sensor networks that monitor traffic flow, air quality, and water systems generate real-time data that’s directly useful during emergencies. Traffic sensors reveal evacuation bottlenecks. Water system monitors detect contamination. Air quality sensors track wildfire smoke patterns.

The catch—there’s always a catch—is that most of this data feeds into siloed city systems. The water department dashboard doesn’t talk to the emergency management dashboard, which doesn’t talk to the nonprofit coordination platform. The integration problem, again. Same song, different verse.

What I’d Build Differently #

If I were building Doare.org today, I’d start with the map. Not the payment flow—though that’s important—not the nonprofit directory, but the map. Show donors where the need is in real time. Show nonprofits where the other nonprofits are working so they can fill gaps instead of duplicating coverage. Show volunteers where their skills are needed most. Transparency as a feature.

The technology stack for this existed in 2011—Ushahidi launched in 2008, after all—but we didn’t have the data density to make it work well. In 2020, between mobile phones, sensor networks, and crowdsourced reporting, the data exists. What’s missing is the integration layer that turns scattered data into coordinated action. The plumbing, basically. Nobody wants to build plumbing.

I think the next generation of disaster relief technology won’t be about any single tool getting better. It’ll be about interoperability—the boring, difficult, unglamorous work of making systems talk to each other so that the person on the ground making decisions has a complete picture instead of six partial ones. Not exciting. Necessary.

The pandemic proved the need. Whether the relief sector builds the solution before the next urban disaster hits—that’s the question I can’t answer. And honestly? I’m not optimistic.