WeMakeDevxAWS Baharth Builds Hackathon
How we built an open-source, serverless heatwave operational decision tool on AWS (Lambda SnapStart, API Gateway, DynamoDB, CloudFront) to translate 72-hour forecasts into actionable NDMA/HAP playbooks for urban ward coordinators.
Master's
# HeatShield: Turning a 72-Hour Heat Forecast into a Ward Action Plan with Java 21 and AWS Lambda SnapStart
*Built solo for the WeMakeDevs Bharat Builds Tour, Environmental Hacks (powered by AWS), Heat and Water track.*
**Live app:** https://d2ijd5tuo68h8.cloudfront.net
**Code (MIT):** https://github.com/manohar-kunda/HeatShield
**3-minute demo:** https://youtu.be/CzfocaChzJs
---
## The problem: a forecast is not a plan
Every summer, Indian cities see forecasts like "44°C on Tuesday." A ward relief coordinator still has to decide the next steps. When should drinking-water points be ready? When should outdoor work stop? Who is responsible, and by what time?
HeatShield is a **planning aid** that answers those questions. It takes 72 hours of hourly forecast data, finds the peak, and produces a role-assigned action list with deadlines and a bulletin the coordinator can copy to WhatsApp or print. It is not an official warning and does not replace IMD or district advisories.
Note: the five wards in the app (Ahmedabad, Delhi, Nagpur, Hyderabad, Kolkata) are **illustrative demo wards**, not real ward boundaries.
## How it works
```
Open-Meteo hourly forecast (72 h)
|
+--> NWS heat index (Rothfusz regression + Steadman pre-check)
|
+--> Indicative IMD-style signal (plains criteria only)
|
v
72-hour peak detection
|
v
Rule-based playbook (JSON), adapted from NDMA guidance
and the Ahmedabad Heat Action Plan
|
v
Actions: owner role, deadline, status, short note
|
v
Bulletin: WhatsApp text or A4 print (English + Hindi draft)
```
### 1. Heat index, with its limits shown
- A Steadman simple formula runs first. If the result is at least 80°F (26.7°C), the full NWS Rothfusz regression (9 coefficients) applies, including the low- and high-humidity adjustments.
- The regression is only validated for air temperature of 80 to 110°F. Above 110°F (43.3°C), HeatShield **flags the value as extrapolated** instead of presenting it as exact.
- Tiers follow the NWS bands (Caution, Extreme Caution, Danger, Extreme Danger), rounded to the nearest °F. For example, Delhi at 26.5°C (79.7°F) rounds to 80°F and shows Caution. This rule is documented and unit-tested.
- The IMD-style signal is **indicative and covers plains criteria only**.
### 2. Actions follow the peak, deadlines come before it
A coordinator who opens the app on a mild morning should still see tomorrow's plan. So:
- **Which playbook applies** follows the highest tier in the next 72 hours.
- **Deadlines** for peak-hour actions are set two hours before the forecast peak. In the live example, the peak is Tue 13 Oct 14:00 IST and the "Before peak" deadline is 12:00 IST.
Both the "Right now" tier and the "Peak in next 72 hours" tier are shown, so the two cannot be confused.
### 3. A What-if simulator and a historical replay
- **What-if:** 38.5°C at 55% relative humidity gives a heat index of 53.3°C (127.9°F), Extreme Danger, with 5 actions.
- **Replay:** a May 2010 Ahmedabad replay built from the raw Open-Meteo archive file (ERA5-based). It is a retrospective illustration, not a claim about outcomes. The archive's maximum air temperature is 45.4°C (21 May 2010, 16:00 IST), and the heat-index tiers appear with the extrapolation notice.
## The AWS architecture
```
Browser / installable PWA
|
Amazon CloudFront --(OAC)--> Amazon S3 (static frontend)
|
/api/* (same origin)
|
Amazon API Gateway (HTTP API)
|
AWS Lambda (Java 21, SnapStart)
|
+--> Amazon DynamoDB (on-demand, TTL)
+--> Open-Meteo API
Amazon EventBridge (every 4 h) --> Lambda
Amazon CloudWatch alarm, AWS Budgets
```
Everything is deployed in `ap-south-1` (Mumbai) from a single AWS SAM template.
**Why Java 21 with SnapStart?** I am a Java developer, and I wanted to see whether Java fits an infrequent public tool. The numbers I measured in CloudWatch:
- SnapStart initialization at publish: about 6 s (paid at deploy time, not per request)
- Snapshot restore on a cold start: about 444 ms
- First call after restore: about 168 ms
- Warm handler: 1.7 to 24 ms
These are measurements from this one deployment and small workload, not a general benchmark.
**Single origin through CloudFront.** Static files come from S3 through Origin Access Control, and `/api/*` goes to API Gateway on the same domain. This removes the need for CORS configuration. A response headers policy adds a Content Security Policy, HSTS and other security headers. API Gateway stage throttling is set to 25 requests/second with a burst of 50.
**Pay-per-use and a cost guard.** Lambda, API Gateway and DynamoDB on-demand all bill by use, which suits a tool with seasonal traffic. An AWS Budget and a CloudWatch alarm watch the stack.
## Privacy by design
Coordinators write notes, and notes can leak personal data. So:
- There are **no accounts**. Each browser gets a random workspace ID.
- Notes are limited to 200 characters. The server **rejects** notes containing 10 or more digits (including Devanagari digits and separators such as spaces, dashes, slashes and commas) or an email address.
- Statuses and notes are stored in DynamoDB with a **7-day TTL**. TTL deletion runs in the background, so removal is not instant.
- The optional helpline field stays in the browser.
The screening is not perfect, and the app tells users not to enter personal details. HeatShield is not designed to collect personal data.
## Built for field use (prototype level)
- Plain JavaScript, HTML and CSS, with no frontend framework and no charting library. The 72-hour chart is inline SVG.
- High-contrast light theme, inline SVG icons (no emoji), no text below 14 px (13 px footer), 44 px minimum touch targets. This is an internal rule targeting WCAG 2.1 AA, **not a compliance claim**.
- An installable PWA caches the app shell and the English and Hindi strings. Status changes made offline are queued and sent when the connection returns. This is a **prototype**, and I have not stress-tested it.
## How I checked it
- 75 JUnit tests, including Rothfusz and tier-boundary cases.
- A 68-check script (`verify-live.ps1`) run against the live CloudFront URL: headers, caching, workspace isolation and the privacy filter.
- A headless-browser check that the "Right now" tier matches across the card, bulletin and print view for all five wards.
- A secret scanner over the full git history and tags that looks for 12-digit IDs, ARNs and emails.
## Honest limits
- Demo wards are illustrative, and the October forecast data is mild.
- **The Hindi text is a machine-assisted draft, labelled "PENDING HUMAN REVIEW".** It needs review by a native speaker before any real use.
- The IMD-style signal is indicative, and the heat index understates dry heat. The replay shows this clearly.
- HeatShield is a planning aid. I make no claims about outcomes or lives saved.
## How I built it, and the AI I used
I directed the project and made the design decisions. **Antigravity generated most of the code.** **Claude helped with planning, prompt writing and reviewing the AI's reports.** The AI tools overclaimed several times, for example by labelling an unverified Hindi review as done and by presenting a synthetic replay fixture as real data. I caught these by demanding raw command output, and the replay now uses the real archive file. My main lesson is to ask AI tools for proof instead of summaries.
## What I liked and what I would change in AWS
- **Liked:** one SAM template for the whole stack, DynamoDB TTL, SnapStart restore times, CloudFront OAC with response headers policies, HTTP API throttling.
- **Hard parts:** CLI session expiry, `sam local` needing Docker, stale CloudFront HTML until cache headers and invalidations were set, and account IDs appearing in CLI output.
## Thank you
Thanks to **Kunal Kushwaha** (LinkedIn: https://www.linkedin.com/in/kunal-kushwaha/ ) and the **WeMakeDevs** team for the Bharat Builds Tour, and to AWS for the platform. Thanks also to the mentors:
- CHANPREET SINGH (LinkedIn: https://www.linkedin.com/in/chanpreet-singh-8891207/ )
- Arkodyuti Saha (LinkedIn: https://www.linkedin.com/in/arkodyutisaha/ )
Feedback is welcome, especially from anyone who works in municipal or public health planning. And if you read Hindi, I would love a review of the draft text.
*Built by Manohar Kunda for Environmental Hacks 2026. Weather data: Open-Meteo.com (CC BY 4.0).*
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article