StateWatch

Inspiration

When a disaster hits, responders need to understand where the danger is, who may need help, and which resources are available. Inspired by State Farm’s “The Worst Day, at Scale” challenge, we built StateWatch to bring that information together. We wanted to help employees prepare before an emergency and keep vulnerable households from being overlooked afterward.

What it does

StateWatch is a disaster preparedness and response dashboard covering tornadoes, earthquakes, hurricanes, wildfires, blizzards, and floods.

Users can explore an interactive U.S. map, filter disaster layers, and inspect affected households, assistance needs, and response teams. Preparedness and response views connect the situation before a disaster with the work needed afterward.

Our backend supports household check-ins, outreach tracking, help requests, and team assignments. We also developed explainable prioritization, overdue-contact detection, and team-matching logic. The prototype uses synthetic households and simulated disaster scenarios.

How we built it

We built the frontend with Next.js, React, and TypeScript, using Leaflet and OpenStreetMap for the interactive map.

SpacetimeDB powers our backend, storing disaster zones, households, requests, teams, assignments, and activity history. Server-side reducers validate operational changes, while subscriptions keep connected dashboards updated.

We created repeatable scenario datasets across all six disaster types and developed rules that consider urgency, vulnerability, hazard severity, and time since contact. Team recommendations account for capabilities, capacity, availability, and distance.

Challenges we ran into

One challenge was turning six different disaster types into a consistent interface without losing the details that make each hazard different. We also had to distinguish geographic context from actual impact areas so the map would communicate exposure clearly.

Keeping operational data consistent was another major challenge. Assigning a team needs to update the request, team availability, and assignment together while preventing conflicting dispatches.

As our datasets grew, we worked on clustering, viewport filtering, and paginated lists to keep the map usable. Coordinating shared schemas and connecting separately developed frontend and backend components also required careful integration.

Accomplishments that we're proud of

We’re proud of building a shared foundation for both preparedness and response, with six disaster types represented in one dashboard.

Our backend validates assignments, enforces employee access, and records operational changes in an activity history. We also built repeatable scenarios and automated checks for authorization, workflow transitions, exposure calculations, and recommendation logic.

We made our decision logic explainable: priority scores include contributing reasons, and team recommendations show eligibility factors and clearly labeled travel estimates.

What we learned

We learned that disaster coordination depends on carefully defined states. A household reporting that it is safe does not necessarily mean its assistance needs are resolved, and an available team may still lack the right capabilities.

We also gained experience with SpacetimeDB subscriptions, transactional backend logic, geographic data, and map performance. Building together reinforced the value of agreeing on data contracts early and testing integration throughout development.

What's next for StateWatch

Our next step is completing the dashboard controls for prioritization, outreach, and dispatch so employees can manage the full workflow from the interface.

From there, we want to integrate live hazard feeds, road-aware routing, shelter and supply information, and opt-in notifications. We also want to validate our prioritization assumptions with emergency-response professionals and expand testing across larger scenarios.