Every October, Delhi’s sky turns a dull grey-brown, and everyone’s phone shows the same number: today’s AQI. It tells you what’s happening now, not what’s coming, and it doesn’t tell you who’s about to breathe the worst of it. So when I joined the Environmental Hacks hackathon (WeMakeDevs × AWS), air pollution was an easy pick. I wanted to build something that looks three days ahead.
The plan was huge. The time wasn’t. My first sketch had everything: satellite data, weather, ground sensors, source attribution, a 72-hour forecast, an exposure map, advice for citizens and authorities, and a what-if simulator. On paper it looked great. Then I looked at the calendar and cut it down. Satellite imagery went first. I focused only on Delhi, with 12 stations, and built a thin version of the whole pipeline before polishing any one part.
Lesson: a small thing that works from end to end beats an impressive architecture diagram.
The data was messier than the diagram Without free API keys for OpenAQ (ground sensors) and NASA FIRMS (fire detections), my first live run gave me coarse model data. All 12 stations looked nearly the same, and the numbers were lower than anything you’d measure on a Delhi street.
Lesson: check what the data actually is before you build a model on it.
My forecast lost to “same as now” This was my favourite surprise. My first run printed a table showing the model was worse than just predicting that tomorrow would match today, by up to 70% at the 48 to 72 hour range.
The reason was simple once I saw it. The model learned mostly from cleaner Aug–Sep air and was being tested on October, when pollution rises. Tree-based models can’t predict beyond what they’ve seen. The fix was to predict the change from the current level and pull the prediction toward “same as now” where the model wasn’t helping. [Add your new numbers after re-running.]
Lesson: always compare against a dumb baseline. A bad result is information, and it’s better to find it yourself than have a judge find it.
Being honest in the product The source breakdown is labelled “indicative”, because it’s rule-based and not chemical analysis. The what-if simulator states its assumptions. The dashboard even shows the forecast’s accuracy table. It felt risky to show the weak spots, but I’d rather be trusted than look perfect.
Deployment adventures I had no Docker, which turned out to be fine. I built the AWS Lambda package as a zip, downloaded Linux versions of the libraries, and trimmed them to fit Lambda’s 250 MB limit.
Working with AI I used Claude to scaffold the code and help debug. It got me from idea to a working pipeline much faster than I could have alone. But it didn’t run my real data, read my error messages, or decide what to cut. I learned to treat AI output like a teammate’s first draft: useful, fast, and in need of checking. I listed it openly in my submission.
What I’d do next Real population data in place of my placeholder surface, more stations, satellite NO₂, and a page that reads fresh data from AWS every hour instead of a snapshot. I’d also want to test the source attribution against real research.
What I’m taking away Build thin and end to end first, then improve. Look at your data before you model it. Always have a baseline, and be glad when it beats you. Label estimates as estimates. Secrets never go in git, and a leaked key is replaced, not deleted. AI speeds you up, but you still own the result.
Merry building!!
Loading article