READI: coordinating the first 72 hours after an earthquake
Four people, 48 hours, and one question nobody could answer: when disaster strikes, what is the go-to tool for communicating and coordinating?
- Context
- Building for Good AI Hackathon
- Role
- Product and team lead. Coordination, brand system, pitch.
- Timeframe
- 48 hours, August 2026
- Working end to end demo shipped and presented inside the time limit
- Model and front end built in parallel by separate sub teams, integrated on the first try
- 313 mapped zones across a 3 phase earthquake scenario, live on stage
The problem nobody had framed
San Diego. 313 census tracts in the modeled area, and a shortage that moves block by block.
In the 72 hours after an earthquake, the failure is rarely total scarcity. It is distribution.
Our team of four people had 48 hours to frame the issue and design the solution. My role was to keep all four of us building toward the same person: a distressed neighbor looking for help.
What I actually did
I set the scope on day one and defended it. We could have built a prediction model, an allocation optimizer, a mobile intake app, and a dispatcher console. We had time for a credible version of two. I made the call: a shortage risk surface and a redistribution plan, and put everything else in writing as deferred, so nobody quietly kept building it anyway.
I ran the team, not the map. Clear workflows, regular check-ins, and enough pointed questions early to catch delays before they cost us hours we did not have. Most of what I was doing in any given hour was making sure the model side and the front end side still agreed on what they were building, and flagging it the moment they did not.
I kept steering us back to the neighbor. The team’s instinct, like most engineers under pressure, was to make the map do more. Mine was to push it to do less. I gave feedback to simplify it and kept reminding the room who was actually going to open this app: someone scared, mid-emergency, who needed it to be obvious, not impressive.
I designed the demo to be lived in, not watched. A judge sitting through a features tour forgets it by the next team. So we built the presentation around a follow-along moment: the room played the neighbor, watching the risk in their own block change in real time as the scenario unfolded. It is the difference between describing a product and putting someone inside it for ninety seconds.
I built the brand system and carried it everywhere. A sage and pine coastal palette, written in code, generated the deck programmatically from those same tokens, then carried through to the live app itself, so nothing in the room ever had to translate between what was on the slide and what was on the screen. I used Claude Code to build all of it.
What it taught me
The engineering was never the hard part. The hard part was deciding, fast and under pressure, what four excited people were not going to build, and keeping everyone pointed at the one person the whole thing was for.
Make the north star so obvious nobody has to ask what they are building toward, whether the countdown is a hackathon or a fiscal quarter.