HomePage
Map_Surveillance
AI_Analyst
Alerts
SMS
Offline_Kit
Alerts
Guide
Printable_Checklist
Proof_Of_It_Being_Printable
In_Spanish
Light_Mode

StormSense

Built for the CSC Summer Impactathon; a project to help my own family stay safe during storms, floods, and heat waves, without relying on a fast connection, a smartphone everyone knows how to use, or power staying on.

Inspiration

This project started with a very specific worry, not a statistic: what happens to the relatives in my family who don't check weather apps, don't have great signal, or don't have a smartphone at all when a storm actually hits?

I thought about my grandparent, who finds out about bad weather from the news or a phone call; not an app. I thought about the times our power (and Wi-Fi) has gone out right when a storm was getting worse, which is exactly the moment you need information most. Official weather sites assume you have a strong connection and know how to read a forecast. That's not true for everyone in my own house.

So I built StormSense to solve a problem I could see happening in my own family: make disaster risk information simple enough that anyone in my family could understand it in seconds, and make sure it still works when the internet doesn't.

What It Does

StormSense is a risk dashboard with an offline safety net underneath it, designed around one rule: reduce the number of decisions a stressed family member has to make.

Feature	Who it's for in my family
Live Risk Map	Color-coded (green → red) so a relative can glance at it and instantly know if today is a normal day or a "pay attention" day — no reading required
AI Risk Analyst	Turns raw weather data into a short, plain-language checklist, so nobody in my family has to interpret meteorology terms themselves
Alert Center	One tap gets a survival guide written for the specific disaster happening right now, not generic advice
Offline Kit	Every guide is saved on the device ahead of time, so it works with zero internet — for the exact moment our Wi-Fi goes down
SMS Simulator	Shows how a short, plain-text alert would reach a relative on a basic phone with no data plan and no apps

Design & User Flow

I designed this thinking about my grandparent specifically: could they open this and know what to do within 10 seconds, without me explaining it? That constraint shaped everything:

Home / Risk Map — open the app, see one color for your area. No login, no setup, nothing to learn.
Alert Center — tap the alert, get a short checklist in plain words, built from the actual current conditions.
Offline Kit — the exact same guide, pre-saved, that works identically with or without internet.

I kept it to three screens on purpose. A family member in the middle of a storm shouldn't have to dig through menus.

How I Built It

Frontend: React + Vite + Tailwind CSS, deployed on Vercel
Live Map: Leaflet.js, pulling live conditions from the OpenWeatherMap API every 5 minutes, drawn as color-coded risk zones
AI Layer: Claude API — every request sends real, structured weather data (not just a location name), so the advice is based on actual current conditions instead of generic tips
Offline Layer: a service worker with a versioned cache (stormsense-v1) that pre-saves the map, guides, and SOS page so they load with no connection
Charts: Chart.js for a 24-hour temperature trend and rain probability, loaded only when that panel is opened, to keep the app fast on older phones

Risk scoring combines live conditions into one score:

$$\text{Risk Score} = w_1 \cdot P + w_2 \cdot V + w_3 \cdot \Delta T$$

where P is precipitation rate (mm/hr), V is wind speed (km/h), and ΔT is how far the temperature is from the seasonal average.

Heat risk uses the standard Heat Index formula:

$$HI = -42.379 + 2.049T + 10.143R - 0.225TR - 6.84 \times 10^{-3}T^2 - 5.48 \times 10^{-2}R^2$$

Above 103°F triggers High; above 124°F triggers Critical.

Flood risk is tiered directly from rainfall rate:

$$\text{Flood Risk} = \begin{cases} \text{Low} & P < 10\ \text{mm/hr} \ \text{Medium} & 10 \leq P < 30\ \text{mm/hr} \ \text{High} & 30 \leq P < 60\ \text{mm/hr} \ \text{Critical} & P \geq 60\ \text{mm/hr} \end{cases}$$

How I Used AI

Per the Impactathon rules, here's exactly how AI tools were part of this project:

As a core feature, not a gimmick. The Claude API is the app's risk-analysis engine. It receives real, structured weather data (location, live conditions, disaster type) and turns it into a plain-language checklist a non-expert relative could follow. My first attempts sent Claude only a location name, and it gave generic, textbook-style advice that wasn't useful; I had to redesign the prompt to include live numbers before it gave advice grounded in what was actually happening outside.
As a coding assistant. I used AI tools (including Claude and coding-assistant tools) to help write boilerplate; setting up the service worker, scaffolding Tailwind components, and debugging why the offline cache was failing silently. I reviewed, tested, and can explain every part of the risk-scoring, caching, and UI logic myself; AI sped up typing, not understanding.

I can walk through any part of this project — why a score is calculated the way it is, why the offline cache is structured the way it is, or why the AI prompt is built the way it is — and explain the reasoning behind it, not just what the code says.

Challenges I Faced

Making Claude context-aware, not generic. Sending live weather JSON with every request, instead of just a place name, turned the AI from a textbook into something that responds to what's actually happening.
Offline mode is harder than it looks. My first service worker cached the wrong files and failed silently — the app claimed to work offline and didn't. I rebuilt it with a versioned cache and a check that runs on load, so the "Offline Ready" badge is actually true.
Keeping alerts simple enough for anyone. 160 characters, no jargon, no markdown: FLOOD RISK HIGH. MOVE TO HIGH GROUND NOW. BRING WATER + ID. CALL 112.
Making it run on an older phone. Leaflet and Chart.js together were too heavy for older, lower-memory Android phones; the exact kind of phone a relative might actually have. Loading the map and charts only when needed cut the initial load time by roughly 60%.

What I Learned

A prompt is a design decision, not just text. How I structured the data I sent Claude directly changed whether the advice was useless or actually usable.
"Works offline" has to be a starting requirement, not an afterthought. I couldn't bolt it on later; it changed how I built almost every screen.
Designing for one specific person (my grandparent) made the app better for everyone, not just the person I had in mind. Simplicity that helps the least tech-savvy person in my family helps everybody.
The people most at risk in a disaster are often the least likely to be the ones checking an app; which means the app has to reach them anyway, on their terms, not the other way around.

Why This Matters to My Family

This isn't a hypothetical use case; it's built around real people in my own house and extended family: a grandparent without a smartphone, a household that's lost power and Wi-Fi during storms before, and family members who wouldn't know how to interpret a raw weather forecast even if they saw one. StormSense is meant to sit on a shared family phone or tablet as the thing everyone checks and trusts, and to still work as a printed-or-cached backup if the internet goes down at the worst possible time.

What's Next for StormSense

Real SMS alerts (via Twilio), so the simulator becomes something my family could actually receive texts from
A way for family members to report what they're seeing locally (flooding, downed trees, power outages) so everyone else in the family knows in real time
Sharing the offline kit with extended family and neighbors who have the same connectivity gaps