One Packet, One Click, One Photo: Wiring Delhi's Pollution Fleet to AWS !! See how we built Hawa Command commanding Delhi's Air using AWS
HawaCommand decides where Delhi's sprinklers and smog guns should go, then proves whether they worked. I built the part that connects it to the real world: how a sensor reading, an officer's approval and a citizen's photo travel through AWS. This is that path, service by service, including what broke.
The Last 500 Metres: Building for the Person Who Drives the Sprinkler
Every air-quality dashboard ends at a map. Ours had to keep going, out of the control room, into a truck cab, onto a street in West Delhi at 6 a.m. This is the story of the part of HawaCommand nobody sees in the demo: the app in the driver's hand.
Full Project Deployed Link : http://ec2-13-207-49-123.ap-south-1.compute.amazonaws.com:3000/#hardware
Full Project Github Link : https://github.com/shankywho/HawaCommand
Full Project Github Link : https://github.com/shankywho/HawaCommand
The plan is not the product
HawaCommand is an AI command centre for Delhi's air. It maps pollution street by street, works out the likely cause of each hotspot, forecasts 72 hours ahead, and drafts a plan for the city's existing fleet: 376 anti-smog guns, 266 water sprinklers and 91 road sweepers. A ward officer reviews the plan and clicks Approve.
My teammate wrote about why that plan needs proof ([LINK TO SHANKAR'S BLOG]). This post is about what happens after the click.
A perfect plan that a driver ignores, misreads or can't follow is worth nothing. So my question was: what does a sprinkler driver actually need from us, and what should we never ask of them?
Who we were designing for
We designed for one person: a truck driver on an early shift, often working on a basic Android phone, in a cab with patchy 4G, who may be more comfortable reading Hindi than English, and who has a supervisor and a route sheet already.
That picture ruled out a lot of ideas quickly:
- No dashboards. A driver doesn't need the PM2.5 heatmap. They need the next stop.
- No typing. Anything that needs a keyboard while driving won't get done.
- No dependence on signal. If the app breaks in a dead zone, it gets uninstalled.
- No English-only. The app ships in Hindi and English from the first screen.
A day in the app
1. Today's route. The first screen is a plain list: today's stops in order, each with a place name, a time window and why it's on the list ("Road dust, school nearby, before 8 a.m. assembly"). The "why" matters. A driver who knows the school gates open at 8 understands why the stop moved earlier than usual.
2. Route map. One tap shows the same stops on a map, so the driver can see the order of the morning at a glance.
3. Stop detail. Each stop opens to what to do there, for how long, and what to watch for.
[CONFIRM: exact fields shown]4. Done, or skipped, with a reason. This is the most important screen we built, and the smallest. When a stop can't be done (a blocked road, a parked bus, a market crowd), the driver picks a reason from a short list instead of silently moving on. A skipped stop with a reason is useful data. A skipped stop with no record looks like a success on paper, and that is exactly the problem HawaCommand exists to fix.
5. Manual done, only when the sensor is offline. Trucks can carry a HawaTag, a small device that records when the pump actually runs. When it's working, the driver doesn't confirm anything; the device does. A manual "done" button appears only when the tag is offline. We didn't want drivers vouching for spraying the system can measure itself.
6. Shift summary. At the end of the shift: stops done, stops skipped and why, time on route. It's a record the driver can show their supervisor, not just a log for us.
Designing for no signal
Delhi has dead zones, and trucks drive through them. Every action in the app (stop done, stop skipped, photo taken) is written to the phone first, in a local queue. When the connection returns, the queue syncs in the background. The driver never sees a spinner, and nothing is lost because a road went under a flyover.
[CONFIRM: describe your outbox/sync behaviour as built]There is also a "Pending uploads" screen in settings, so if something is waiting to sync, the driver or a supervisor can see it rather than wonder.
The same app, other people on the street
The driver app is one role in a single Flutter app. The same codebase serves the rest of the people the plan touches:
- Inspectors get a list of targets (a site burning waste, a construction site raising dust), visit them, and record the outcome with photo evidence.
- School principals see the morning forecast and a safe window for outdoor activity, so assembly moves indoors before the worst hour, not after.
- Citizens see the air near them, get alerts, and can report open burning or a sprinkler that never came.
Each person sees only their own screens; none of them has to learn the officer console.
below is the citizen view
Here we do have the RAW Hardware view :
Closing the loop from the street
What the driver does feeds straight back into the system. A completed stop, with the HawaTag's spray log, is what lets HawaCommand's verifier compare that street with similar untreated streets and measure whether the air actually improved. A skipped stop with a reason tells the next plan which roads are unreliable at that hour.
In other words, the driver isn't at the end of the pipeline. They're the start of the evidence.
Where it runs
The app talks to a backend running on AWS in Mumbai. Evidence photos go straight from the phone to Amazon S3 through short-lived upload links, so the phone never holds credentials, and dispatch notifications reach drivers when an officer approves a plan. The details are in our team's architecture write-up; for the driver, all of it should be invisible.
What we are not claiming
- No real MCD driver has used this app yet. The fleet and the routes in our demo are simulated.
- HawaTag is a prototype design; in the demo, its signals come from a simulator.
- We haven't tested the app on the oldest, cheapest phones a city fleet might use. That is the first thing to do before any pilot.
What I learned building for the field
- The smallest screen mattered most. The skip-reason picker took an afternoon to build and says more about real-world performance than any map.
- Never ask a person to confirm what a sensor can measure. Manual confirmation is a fallback, not the default.
- Offline is a feature, not an edge case. If it doesn't work under a flyover, it doesn't work.
Try it
- Live console: http://ec2-13-207-49-123.ap-south-1.compute.amazonaws.com:3000/#hardware (open Plan #214, approve it, then see the routes it produces)
- Code: https://github.com/shankywho/HawaCommand
- The product story: https://builder.aws.com/content/3KXDuEGnSKh8GBIlB0BQJvDdvPC/the-sprinkler-nobody-measured
Built for Environmental Hacks 2026, Air track, WeMakeDevs × AWS Bharat Builds Tour, by Team Straw Hat Pirates. AI coding assistants helped with implementation and drafting; I'm responsible for every claim here.
If you've built software for people who work outdoors: what did they need that you didn't expect?
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article