-
Guardian Response panel lets users register vulnerable neighbors and coordinate volunteer help in real time.
-
Volunteer availability toggle and live assignment matching for community-based disaster response.
-
Register a vulnerable person with name, address, phone, and specific needs like elderly, disabled, or medical.
-
Guardian Response tab with full registration form to connect vulnerable residents with nearby volunteers.
-
Smart geocoded search with autocomplete for cities, districts, and landmarks across any region.
-
Risk score gauge, live weather metrics, and nearby disaster tracking in a clean, glanceable layout.
-
One-tap community reporting for flooding, power cuts, road blocks, strong winds, and fire or smoke.
-
Full dashboard in demo mode showing live risk score, weather bar, map with shelters, and Guardian ops panel.
Inspiration
Disasters don't wait for dashboards to load. We built GuardNet after seeing how communities are left scrambling with fragmented, delayed information when every second counts. We wanted to turn raw weather chaos into coordinated, neighbor-to-neighbor action—so people know where to go, what to do, and who needs help before panic spreads.
How we built it
We started with a React + TypeScript frontend powered by Vite and styled with Tailwind CSS for a fast, responsive UI. For the backend, we used Firebase (Auth, Firestore, and Hosting) to handle real-time community reports and user authentication without managing our own servers.
We fused multiple data layers into a single live risk score: OpenWeather for forecasts and severe alerts, Mapbox for interactive maps and geocoding, and OpenRouteService for evacuation routing and path scoring. To bridge the gap between raw data and human action, we integrated OpenRouter to generate concise, real-time AI narration that tells users exactly what the risk means for them.
We also built the app as an offline-first Progressive Web App using Service Workers and the Cache API, so critical data and maps remain accessible even when cell towers go down.
Challenges we faced
The hardest part was fusing multiple APIs—weather, geospatial, and routing—into one coherent, live risk score that updates in real time without overwhelming the user. We also spent significant time stress-testing the UI to make sure it stays readable and actionable under emergency conditions, not just in a calm demo.
Making the app truly offline-first was another major hurdle: we had to carefully cache map tiles, risk data, and fallback routes so the app doesn't become a brick when networks fail during a disaster.
Finally, building Guardian Mode—which dispatches location-aware alerts to trusted volunteers and local agencies—required balancing speed with precision, so we could prioritize reports by severity and proximity without flooding responders with noise.
What we learned
Real-time geospatial coordination is hard, but it's the difference between chaos and community. We learned that AI narration isn't a gimmick—it's a critical bridge that turns raw numbers into life-saving instructions. Most importantly, we learned that for disaster tools, offline resilience isn't a nice-to-have feature; it's survival.
Built With
- api
- cache
- firebase
- mapbox
- openrouter
- openrouteservice
- openweather-api
- react
- service-worker
- tailwind-css
- typescript
- vite
Log in or sign up for Devpost to join the conversation.