RideClean: Turning Delhi’s Air Pollution Data Into Actionable Insights for Delivery Riders
Every winter, Delhi’s pollution becomes a daily reality for delivery riders who cannot simply stay indoors. We built RideClean using AWS, OpenAQ data, and an exposure-aware decision system to turn air-quality data into practical recommendations for riders and the people managing their rest infrastructure.
RideClean: Turning Delhi's Invisible Pollution Into Something a Rider Can Understand
Every winter, Delhi's air becomes something you can almost see.
For most of us, that means checking the AQI before leaving home, closing the windows, or deciding to work indoors. For a delivery rider, it means something very different. You cannot simply stay inside. Every order means another trip through traffic, another few kilometres on a two-wheeler, and another stretch of time breathing the same air that pollution dashboards reduce to a single number.
That made us ask a simple question:
What does Delhi's pollution actually cost a delivery rider during a working shift?
More importantly, can technology help a rider make a safer decision without asking them to stop working?
That question became RideClean, our project for the WeMakeDevs × AWS Environmental Hacks.
RideClean is a pollution-aware assistant designed for two people who experience the problem differently: delivery riders who have to move through polluted streets, and station managers who can decide where riders can safely take breaks.
We wanted to turn air-quality data into something actionable.
Not another AQI dashboard.
Not another red-orange-green pollution map.
Something that answers a much more practical question:
"If I take this ride right now, how much pollution am I likely to breathe, and is there a better option?"
We Started With the Data
For the first version of RideClean, we used historical air-quality data from the OpenAQ archive on AWS Open Data.
The dataset allowed us to work with hourly PM2.5 measurements from government monitoring stations across Delhi NCR. We processed data from 57 monitoring stations, covering 75,894 station-hours between 15 October and 15 December 2025.
We built a Python data pipeline to download, clean, aggregate and analyse the measurements before feeding them into the application.
The first results were worse than we expected.
Across our dataset, average PM2.5 was approximately 12.9 times the WHO guideline level, while 96.9% of the recorded hours exceeded India's national PM2.5 standard.
Even more interesting was the time-of-day pattern. The highest pollution exposure in our dataset was concentrated around 10 PM to 2 AM.
That matters because delivery work does not necessarily stop when pollution gets worse. In fact, late-night delivery can put riders directly into one of the worst exposure windows.
The data gave us our first important insight:
A pollution-aware assistant cannot simply say that today's AQI is bad. It needs to understand time, location and exposure.
From Micrograms to Something a Human Can Understand
There was another problem.
Even after collecting all that data, we still had a communication problem.
What does 193 µg/m³ of PM2.5 actually mean to someone sitting on a motorcycle?
Numbers are precise, but numbers are not always intuitive.
So we experimented with an exposure metaphor: cigarette-equivalent exposure.
Using the Berkeley Earth estimate that approximately 22 µg/m³ of PM2.5 sustained over a day corresponds roughly to the particulate exposure from one cigarette, we could translate pollution concentration into a much more understandable scale.
We also incorporated evidence from an on-road Delhi study suggesting that people travelling on roads can experience substantially higher exposure than measurements from nearby fixed monitoring stations indicate.
Using these assumptions, a representative 10-hour riding shift in our dataset corresponds to roughly 3.3 cigarette-equivalents of PM2.5 exposure.
But we were careful about what this number means.
It is not a literal count of cigarettes inhaled. It is an exposure analogy derived from ambient PM2.5 measurements and published assumptions. It is not a personal medical measurement or a substitute for a wearable pollution sensor.
We did not want to scare riders with a flashy number. We wanted to give them a number they could understand while being transparent about its limitations.
We Didn't Want to Build Another Dashboard
A dashboard would have been easy.
But a dashboard was not the product we wanted.
A rider does not need another graph. They need an answer.
So RideClean became an assistant.
Imagine a rider saying:
"Anand Vihar se Rajiv Chowk."
Instead of simply returning a route, RideClean can combine pollution conditions with the rider's journey and respond with information such as estimated pollution exposure, whether another departure time may be better, the relative pollution risk of the journey, nearby places where the rider can take a break, and the nearest metro station or designated rest location.
The idea is simple:
Convert environmental data into a decision.
The AWS Architecture Behind RideClean
Under the hood, RideClean is a collection of AWS services working together rather than a single monolithic application.
The rider-facing application is built using React and hosted through AWS Amplify Hosting.
Our backend uses a Python AWS Lambda function exposed through a Function URL. The Lambda contains the initial decision-making layer, a rules engine that interprets pollution conditions, rider requests and exposure estimates.
For voice interaction, we integrated Amazon Polly, allowing RideClean to communicate responses naturally rather than forcing a rider to stare at a screen while working.
That matters in this particular use case.
A rider should not have to read a paragraph of text while sitting on a motorcycle. They should be able to hear the important information.
We also use Amazon DynamoDB to record trip information, with a 30-day TTL so that old trip records automatically expire.
This was important to us because an environmental-health product should not casually accumulate personal movement data forever.
Designing for the Moment the Internet Disappears
There is another reality of delivery work: the network is not guaranteed.
A rider can move through areas where connectivity becomes unreliable. If the application becomes useless the moment the internet disappears, it fails precisely when it is needed.
So RideClean includes fallback behaviour using on-device answers for supported scenarios.
The principle was simple:
Connectivity should improve RideClean, not determine whether RideClean works at all.
RideClean Has Two Users
One of the most important things we learned was that the rider is not the only person who can change the outcome.
A rider might know that pollution is dangerous, but can they simply decide, "I'm not working tonight"?
Usually not.
That is why RideClean has a second interface: the Station Planner.
The planner allows managers to look at pollution patterns across zones and hours and identify where rider rest infrastructure could have the greatest impact.
It provides a way to understand pollution by location and time, simulate interventions such as introducing a 15-minute indoor break, and identify potential locations where new rest points could have the greatest value.
This changes the question from:
"How can we tell riders to protect themselves?"
to:
"How can the system around riders make protection easier?"
That distinction became central to the project.
The Feature We Wanted Most Didn't Work
The most important part of our development journey was also the part that did not go according to plan.
We originally wanted RideClean to go beyond a rules engine. We built an agent using Strands Agents and Amazon Nova so that riders could ask free-form questions and receive more flexible responses.
The architecture was ready.
The code was ready.
The idea was ready.
Then we deployed.
Amazon Bedrock returned:
"Operation not allowed."
Our new account did not have the required model access, so every model request failed.
We had to make a decision.
We could spend the remaining time fighting infrastructure problems, or we could make sure the product itself worked.
We chose the latter.
The production demonstration therefore uses our deterministic rules engine for the core recommendations, while the agent architecture remains part of our next iteration.
That failure taught us more than a successful deployment might have.
We learned that cloud development is not simply about writing code and deploying it. Permissions, service access, account limits and quotas can become just as important as the application itself.
We also encountered a Lambda reserved-concurrency limitation on our fresh AWS account and an authentication issue while working with
aws login .Our biggest engineering lesson became clear:
Set up cloud permissions, model access and service quotas on day one, not on the final day of a hackathon.
Then We Spoke to a Rider
The most important validation did not come from AWS.
It came from a person who actually does the job.
One delivery rider told us that he does not have a fixed pollution break. Even if an application tells him that the air is dangerous, he cannot always change his shift.
That statement changed how we thought about the problem.
You cannot solve a structural problem by simply telling the individual to make better choices.
A rider may not control when they work, where they go, or whether they can refuse an order.
But the system around that rider can potentially control where they rest, when protected breaks are provided, and where pollution-aware infrastructure is located.
That is why the Station Planner became much more important to us.
We did not want RideClean to become another application that simply tells individuals to "be careful." We wanted it to explore how the environment around workers could be designed to reduce exposure in the first place.
What We Built Is Small. The Problem Isn't.
RideClean is not claiming to solve Delhi's air pollution.
No application can do that.
Our goal is much more specific: take environmental data that already exists and turn it into decisions that are useful to people who have to work outside.
The data pipeline tells us where and when exposure is highest.
The exposure model translates raw PM2.5 into an understandable metric.
The rider assistant turns that information into an action.
The Station Planner moves the conversation from individual behaviour to infrastructure.
The AWS serverless architecture gives us a path to scale the system without building a large traditional backend.
What's Next?
Our current system is only the beginning.
The next version of RideClean will focus on completing the Strands Agents and Amazon Nova integration once the required Bedrock model access is available.
We also want to add a real places and location layer so that RideClean can identify actual rest points around a rider instead of simply providing generic recommendations.
Most importantly, we want to test the system with more riders, compare our predictions against personal measurements where possible, and understand how people actually use pollution recommendations during a shift.
The Bigger Idea
Delhi's pollution problem is often represented as a number.
AQI: 300.
PM2.5: 193.
Visibility: poor.
But numbers do not experience pollution.
People do.
And some people have the luxury of going indoors while others do not.
A delivery rider cannot close the office window because their office is the road.
That is the gap RideClean is trying to address.
We started with a dataset containing tens of thousands of hourly measurements. We turned those measurements into an exposure model. We turned the model into a rider assistant.
Then we built a second layer that asks an even bigger question:
What if we designed the environment around the rider instead of simply asking the rider to adapt to the environment?
That is the direction we want RideClean to take.
Because the future of environmental technology should not just be better pollution dashboards.
It should be better decisions for the people who have to live and work inside the data.
Built With AWS
RideClean brings together AWS Open Data, AWS Amplify Hosting, AWS Lambda, AWS SAM, Amazon DynamoDB and Amazon Polly, with Strands Agents and Amazon Nova planned as the next stage of the system.
The project is open source:
github.com/Goyamjain06/Edge_testcase
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article