How Two Strangers Can Save Your Evening: Building a Flood-Aware Route Planner for Delhi on AWS
Every monsoon, maps send Delhi riders straight into flooded underpasses. We built DilliJalNav Edge on AWS at Environmental Hacks to fix that. Here is what we built, what broke, and the five lessons we are taking into everything we build next.
Every monsoon, Delhi takes the same photograph.
A DTC bus stands in brown water up to its windows under Minto Bridge. Two cars are stuck behind it with their hazard lights blinking. A man in a soaked shirt pushes his scooter out of knee-deep water, and the engine is long dead.
The photo goes viral. The caption is always some version of one word: again.
We have seen that photo every year of our lives. This year, the four of us asked a different question.
How did that rider end up there?
The answer is uncomfortable because it is so simple. His map told him to go that way. The app knew about traffic, accidents and the fastest way to Connaught Place. It did not know about the water.
This is the story of how we tried to fix that in a single day at Environmental Hacks by WeMakeDevs and AWS. It is about what we built, what broke, the people we met, and the lessons we are taking into everything we build next.
We entered Track 02: Heat and Water. Climate change is making Delhi's monsoon rain shorter, heavier and harder to predict, and the city's drains were never built for that. We chose the water side of the track because it is where climate turns into an everyday safety problem for millions of commuters.
The problem nobody's map can see
Delhi's underpasses are engineering marvels for 360 days a year. Then the monsoon arrives and some of them become small lakes in under an hour.
For a car, that is a ruined evening. For a two-wheeler rider, an auto driver or a delivery partner, it can be dangerous. Water hides potholes and open drains, kills engines and turns a 3 minute shortcut into a night of pushing a dead bike home.
The information already exists. The people standing near Minto Bridge know it is flooded. They can see it. The tragedy is that this knowledge never reaches the rider who is two kilometres away and about to turn in.
So we set ourselves one sharp goal.
Get the knowledge of people on the ground into the route of the person on the way.
The day it all came together
We reached the venue early, collected our swag (bottles, stickers and the laptop decorations that will outlive our degrees) and walked into an auditorium full of people who had the same look in their eyes. Everyone wanted to build something that mattered.
The AWS team ran the whole event. There were introductions, speaker sessions and a hands-on AWS workshop that was refreshingly practical. Nobody explained what the cloud is. They showed us how to ship to it.
We did not come with an empty folder. We came with an earlier project of ours called PathFinder, a camera-based pothole detector, and a question: could we turn it into something that keeps people out of floodwater? By the end of the day, the answer was a live product running on AWS.
What we built: DilliJalNav Edge
DilliJalNav Edge is a mobile web app that checks your route against fresh waterlogging reports from people nearby, before you ride into trouble.
We chose one real corridor for the pilot, because a small thing that works beats a big thing that only works in slides. The route runs from JLN Marg near Ajmeri Gate to Connaught Place, and it has two real options.
- Route A goes through the Minto Bridge underpass. It is 1.7 km and about 3 minutes.
- Route B goes over Shivaji Flyover and Barakhamba Road. It is 3.2 km and about 4 minutes.
On a dry day, the app suggests Route A and says so honestly: "No current waterlogging reports on the assessed segments."
Now picture two people near Minto Bridge. One of them opens the app and says, in the most Delhi way possible, "Minto Bridge ke neeche 3 foot paani bhara hai." The app understands the Hinglish, turns it into a structured report and asks, "We understood this. Is it right?" before anything is sent. A second person taps Water on the road.
Within seconds, every rider planning that trip sees the route through the underpass marked AVOIDED. The app suggests the flyover instead and tells you exactly what it costs: +1 minute, +1.5 km. Then it explains why, in plain words:
"Two or more separate contributors agree. This is agreement, not physical verification."
That last sentence is our favourite line in the entire codebase. Here is why.
The hardest problem was not the code. It was trust.
Making a road turn red when someone complains is easy. The hard question is this: when do you turn it green again?
Most apps hide that decision behind a confidence score that nobody understands. We wrote a small, transparent policy instead, and every underpass is always in exactly one state.
- UNKNOWN. No fresh reports. We say clearly that this is not the same as dry.
- REPORTED. One person saw water. The underpass is avoided.
- CORROBORATED. Two different people agree. Still avoided, with more confidence.
- CONFLICTED. Someone newer says there is no water. We keep avoiding it until a reviewer checks.
- STALE. The reports are older than 30 minutes. We still avoid it.
- RECENTLY CLEAR REPORTED. A reviewer accepted two newer "no water" reports. Only now does the route open again, and it is labelled as unofficial.
Read STALE one more time. When the reports go quiet, most systems quietly go back to "all clear". Ours does not. In a flood, silence is not good news. The app says "I cannot confirm conditions" and keeps you away until a real person says the road is clear.
We also refused to let anyone fake a crowd. Each source counts only once. If your phone retries the same report on a bad network, it never becomes a second witness. If someone reuses a report ID with different content, the server rejects it outright. And anyone can tap "Why this route?" to see every source, how old it is and the exact rule that made the decision.
People forgive an app that says "I am not sure". They never forgive one that sends them into water with a confident green line.
On the road: a co-pilot that lives in your pocket
Planning only solves half the problem. The other half happens on the road, so we brought back our PathFinder camera and made it smarter.
When you tap Start ride, the phone on your handlebar becomes a co-pilot. Two AI models run directly in the browser, so no video ever leaves your phone.
- A YOLOv8n model spots potholes and estimates how deep they look.
- A SegFormer model checks, about once a second, how much of the road ahead looks like water.
When the camera sees possible water, it reroutes only you for the next 20 minutes, warns you out loud in Hindi or English and saves a short dashcam clip. It never files a public report on its own. A camera guess should protect you. It should never reroute the whole city.
Not everyone wants a camera on their handlebar, so we built Pocket mode too. The camera stays off, the screen goes black to save battery, and a calm voice guides you turn by turn with a warning as you approach a flooded hotspot.
Here is the whole journey in one picture. On the left, the planner on a laptop checks the trip from JLN Marg to Connaught Place. On the right, the same app runs on a phone on the handlebar, watching a waterlogged underpass ahead while the dashcam records and live GPS guidance runs on a 3D map.
Under the hood: how we used AWS
We wanted a backend that is boring in the best possible way: serverless, cheap when nobody is using it, and easy to rebuild from scratch.
- Amazon CloudFront serves the app and the API from one domain. That removed every CORS headache and gave us HTTPS, which the phone camera and GPS need anyway.
- Amazon S3 holds the app and the AI models in a private bucket that only CloudFront can read, using Origin Access Control.
- Amazon API Gateway (HTTP API) sits in front of everything with throttling at 10 requests per second and bursts of 20.
- AWS Lambda runs three small Python functions on arm64 Graviton. One accepts reports, one understands Hinglish and one makes route decisions. Each has its own logs and only the permissions it needs.
- Amazon DynamoDB stores every report using TransactWriteItems. The report, its duplicate check and the new state of the underpass are written together or not at all. We fired 6 reports at the exact same moment in our live test and lost none.
- Amazon Bedrock reads messy Hinglish through the Converse API, with a 2 second circuit breaker. If the model is slow, simple rules take over and the user never sees an error. The model is also not allowed to invent places: every location must be on our known list and actually appear in what the person wrote.
- AWS SAM describes the entire stack in one template. One command builds it. One command deletes it.
Before we called it done, we ran a 12-scenario smoke test against the live AWS URL, not our laptops. It covered duplicate reports, conflicting retries, corroboration, the route switch, concurrent writes, stale evidence and a simulated failure. 12 out of 12 passed.
The part where everything broke
No honest build story is complete without this part.
Our first deploy kept failing at the sign-in step, again and again. We were pointing the AWS CLI at the wrong Region, and nothing told us. Then we found one API route missing from our template, which meant the app's voice quietly fell back to the phone's robotic one. And on demo day itself, our beautiful dark Google map suddenly turned into a plain beige one.
For a few minutes we were sure the deployment had broken everything. It had not. Our Google Maps demo key had simply hit its daily limit after a morning of heavy testing, and the app had done exactly what we designed it to do: it fell back to OpenStreetMap instead of showing a blank screen.
That moment taught us more than any workshop. The fallback we built "just in case" saved our demo on the day it mattered.
The best part of the day had no code in it
Between sessions, we stepped out of the auditorium and started talking to people. AWS team members, mentors, other participants. We swapped LinkedIn profiles, opened our laptops on random tables and showed the app to anyone who would look.
Two visiting builders from abroad spent a long time with us, and the conversation went far beyond this project. We talked about how to think about a startup, how to find the right people and how to explain an idea so that someone still remembers it the next morning.
The mentors were generous and sharp. Every question they asked made the product better, and a few of them have stayed with us since.
- "Who is the first person who would use this every single monsoon?"
- "What happens when the data is wrong?"
- "Can you explain it in one sentence?"
Here is our one sentence: DilliJalNav Edge tells you when your usual underpass is flooded, before you get there, and is honest about how sure it is.
By evening we understood something. The event was a hackathon on paper, but the real value was in the people. We came for the code and left with a network.
Five things we are taking with us
1. Trust is a feature, so design it on purpose. Users do not abandon safety apps because the buttons are ugly. They abandon them the first time the app lies. "I cannot confirm this" turned out to be more powerful than any green line.
2. Ship a thin slice, end to end. One corridor and one underpass sounds small. But it is real, it is complete and it is live. A finished small thing teaches you more than an unfinished big one.
3. Test where your users live. Our laptop said everything was fine. Only the live deployment showed us the missing route. Testing against the real URL is now a habit for us, not an afterthought.
4. Every dependency will fail you eventually. Bedrock has a rules fallback. Google Maps has an OpenStreetMap fallback. The camera has a map-only mode. Real phones on real roads with real networks fail in creative ways, so build for it from the start.
5. The room is part of the product. Ten minutes with the right mentor can save ten days of building the wrong thing.
Where we go from here
DilliJalNav Edge is a pilot, and we know exactly what comes next.
- More hotspots. Every underpass needs its geometry checked by a person before it goes live, and we are building that review process now.
- Accountable reporting. Sign-in with Amazon Cognito, so that live community reports come from real people who can be trusted over time.
- Sharper eyes. A camera model trained on Indian roads that can tell potholes, waterlogging, stalled vehicles and blockages apart.
- Partners on the ground. Delivery fleets, auto unions and civic bodies already know where the water collects every year. We want that knowledge in the map.
Our long-term goal fits in one line. Nobody in Delhi should learn about a flooded underpass by driving into it.
The team behind it
We are four builders who split the work cleanly and met in the middle.
- Utkarsh Singh led the project, designed the evidence policy, built the backend and deployed the AWS stack.
- Pranav Pant built the frontend, the map experience and the layouts for phones, laptops and car screens.
- Granth Chhabra built the on-device AI, the ride screen and the speed-adaptive dashcam.
- Adhyan Saxena built the reporting flow, worked on Hinglish understanding with Amazon Bedrock, prepared the corridor data and wrote the tests.
Try it yourself
Open it on your phone, choose Two-wheeler rider and look at the route through Minto Bridge. Then imagine it is July, it has been raining for an hour, and two strangers near the underpass just saved you an evening.
If you are building anything around mobility, climate or civic tech, we would love to talk. The biggest lesson of this event is that ideas get better in other people's hands.
Thank you to WeMakeDevs and the AWS team for a day that taught us far more than we came for.
See you at the next one. And if it is raining, check your route first.
Cover image: screens from the live app. The camera view uses "Shipton Low Road, on a wet day" by Christine Johnstone, licensed under CC BY-SA 2.0.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article