AWS Builder Center

JalDrishti

Bharat Builds Tour, Environmental Hacks, Heat and Water track. Team Dharti Kavach.

Developer

JalDrishti

Bharat Builds Tour, Environmental Hacks, Heat and Water track. Team Dharti Kavach.

The problem: old news travels fast

Every monsoon, the same photo of a flooded underpass goes around Delhi's WhatsApp groups. Is it from today or from last year? Is the water still there? In summer the question becomes "how hot is it really in my area?", and when the tap runs dry, "is a tanker coming?".
The information exists. What's missing are the three things you need before you act on it: where it came from, how old it is, and whether anyone else has seen it.

What I built




JalDrishti (जलदृष्टि, "water vision") is a Hindi-first map of heat, waterlogging, water leaks and tanker needs in Delhi, with an English toggle. Every item on it answers those three questions.
  • Live weather for six points across Delhi: temperature, feels-like, humidity and a 48-hour chart. It's labelled as a model estimate, not a station reading, and shows both "valid at" and "fetched at" times.
  • Community reports: pick a category, tap the spot on the map, name the area, send. The report appears at once as Unverified and Fresh, with a server timestamp.
  • Corroboration: other people tap मैंने भी देखा ("I saw it too"). Two confirmations from different people make a report "confirmed by others" and make it fresh again. You can't confirm your own report, and each person gets one response per report.
  • Share on WhatsApp: every report has its own link with a preview card, because WhatsApp is where neighbours already are.
  • Read-aloud: a 🔊 सुनें button reads the weather or a report aloud in Hindi or English. It's for the people most at risk in a heatwave: older residents and anyone who finds reading hard.
  • Honest gaps: IMD warnings, groundwater levels and real tanker availability have no public, documented data source, so the app says "Not available" and points to the official source or helpline instead of guessing. An empty map says plainly that no reports does not mean no problem.

The architecture

Plain text
Browser (React + Vite)
├─ static site ─────────────► AWS Amplify Hosting
├─ weather (CC BY 4.0) ─────► Open-Meteo
├─ map tiles ───────────────► OpenStreetMap
└─ /reports, /speech ───────► Amazon API Gateway (HTTP API)
└─► AWS Lambda (Node.js 22, arm64)
├─► Amazon DynamoDB (on-demand, TTL)
├─► Amazon Polly (voice: Kajal)
└─► Amazon CloudWatch (logs + error alarm)
The whole backend is one AWS SAM template.
  • DynamoDB, single table: reports, one item per (report, person) response, and rate-limit counters. A secondary index lists active reports without a scan. Conditional writes make retries safe, a transaction records a response and updates the counters together, and TTL deletes reports 30 days after submission.
  • Lambda: input validation shared with the frontend (one module used in both places), server timestamps (never the phone's clock), rate limits and near-duplicate detection.
  • Privacy: no accounts, names or phone numbers. For "one response per person", the API stores a salted, daily-rotating hash of IP + browser, never the IP itself. Logs are one JSON line per request, with no IPs and no report text.
  • Least privilege: the Lambda can do five DynamoDB actions on this one table, plus  polly:SynthesizeSpeech , and nothing else.

What fought back, and what it taught me

1. "Something went wrong" really meant "wrong region"

My first  aws login  ended on an AWS page that said "Something went wrong" and mentioned an appeal. CloudShell said "Unable to create the environment". Neither said why. The answer finally came from Amplify: "Region Asia Pacific (Mumbai) unavailable. Your project is assigned to Asia Pacific (Sydney)." New AWS Free plan accounts are limited to one region. Once I used  ap-southeast-2 , everything worked.
Lesson: when one service gives you a vague error, try another one. Sometimes a different service tells you the real reason.

2. My laptop's clock was 10 minutes fast

With the right region, sign-in failed with  TOKEN_EXPIRED . Windows had never synced its clock (my network blocks time sync), and it was 598 seconds ahead of AWS. AWS rejects credentials when the clocks disagree by more than a few minutes. I set the clock from the  Date  header of an AWS HTTPS response, and sign-in worked immediately.
Lesson: authentication depends on time. Check your clock before blaming the cloud.

3. The map needed a card I didn't have

Google Maps needs a billing account, and my card was declined. Instead of waiting, I switched to Leaflet with OpenStreetMap tiles: no key, no card. One CSS filter ( invert(1) hue-rotate(180deg) ) gives the light tiles the app's dark look, and the OpenStreetMap credit stays visible, as their tile policy requires.
Lesson: a dependency that needs payment is a deployment risk. Keep an open alternative in mind.

4. A public voice button can turn into a bill

Text-to-speech behind a public API could let anyone make my account read anything, at my cost. So the server writes every sentence itself, from stored reports and a fixed list of places. The browser can only ask "read report X" or "read the heat at point Y". Each person can play 20 clips an hour, the whole site 500 a day, and repeated sentences are cached inside the Lambda. Even if someone tries to abuse it, the worst case is a dollar or two a day. Normal use costs cents.
Lesson: for every paid API you expose, work out the worst case before you launch.

5. Screenshots found a bug the tests missed

I drove the site with a headless browser to take phone screenshots. While filling in a report, the script tapped the map right on top of a heat reading. That opened the heat panel and threw away the half-filled form. Real people tapping "right here, where the problem is" would hit this all the time. Now, while you're reporting, the map pins dim and let taps pass through to the map.
Lesson: test the flow the way a hurried person on a phone would use it.

6. Honesty is a design decision

The hardest calls were about what not to show: no fake "official" badges, no guessed groundwater levels, no invented tanker data. The weather says "model estimate, not a station reading". The voice says "this is not an official warning". Holding back made the product more trustworthy, not less.

Tips if you're deploying from a new AWS account

  • Find out which region your account is assigned to before deploying anything. Amplify's error message tells you.
  • Use  aws login  (AWS CLI 2.32 or newer): no access keys on your laptop. Keep your system clock in sync.
  • Set a $5 budget alert first. It's free, and the new console even lists it as an activity that earns credits.
  • Read the changeset before applying it.  sam deploy --no-execute-changeset  shows exactly what will be added, modified or removed.

Cost

Everything is pay-per-request: API Gateway, Lambda, DynamoDB on-demand and Polly per character. Nothing sits running. A demo weekend costs well under a dollar, covered by Free plan credits.

What's next

  • Official alerts: India's NDMA "Sachet" feed publishes official alerts, including IMD warnings. Browsers can't read it directly, so a Lambda would fetch and cache it.
  • Photo evidence with size and type limits (S3 pre-signed uploads) and moderation.
  • A missed-call or SMS path for people without smartphones.
  • The Mumbai region, closest to Delhi, once the account allows it.
Try it: open  https://main.d3d8k3q572kn9v.amplifyapp.com , report something you can see, share it with someone nearby, and ask them to tap मैंने भी देखा from their own phone.
Built for the Bharat Builds Tour, Environmental Hacks (Heat and Water), October 2026.
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article