The Forecast Says 40°C. Now What? Building veryHOT.ai with AWS
A weather app can tell you how hot it is. But can it help you decide what to do about it? That question led us to build veryHOT.ai, a Hyderabad-focused heat-awareness web app for WeMakeDevs Environmental Hacks 2026. This is the story of the people behind the problem, our idea, how we used AWS Lambda and Amazon API Gateway, the data challenges that humbled us, and what we learned about building technology that genuinely matters.
Student
The Forecast Says 40°C. Now What?
Imagine you're heading to college on a hot afternoon in Hyderabad.
Your bike is already warm before you even start it. The road feels like it's radiating heat back at you. You check your weather app, see the temperature, close it, and continue with your day.
But what did you actually learn?
You know it's hot. You probably knew that before opening the app.
Now imagine someone working outdoors for hours, a delivery partner riding across the city, or a family member deciding how to plan the day for an older parent. For them, heat isn't just an uncomfortable notification. It affects how they work, travel, take breaks, and look after the people they care about.
And here's the thing: knowing the temperature and knowing what to do about it are two different things.
We have more weather data than ever, but turning that data into a useful everyday decision still takes effort from the person looking at the screen.
That was the problem we wanted to explore.
Not how to make another weather dashboard. Not how to put an AI chatbot on a map just because AI is having its moment.
We wanted to answer a much more human question:
“Given the conditions today, what should I consider doing differently?”
That question became veryHOT.ai.
From “What if?” to “Okay, let's build it.”
We started working on veryHOT.ai for WeMakeDevs Environmental Hacks 2026, under the Heat and Water track.
The idea was simple enough to explain to anyone, which was a good sign. We wanted to take real weather forecasts, understand the role of humidity and apparent temperature, and present practical precautions that people could use while planning their day.
The first version didn't need to predict the future of climate change or solve every water-related problem in Hyderabad. We needed a clear, useful starting point.
So we focused on three things:
- Show current weather conditions and the upcoming hourly forecast.
- Provide a transparent, supplementary heat assessment using apparent temperature and relative humidity.
- Translate those conditions into understandable precautions instead of leaving users with a collection of numbers.
In other words, we wanted the app to do a little more than say, “It's hot.”
We wanted it to say, “Here's what the forecast indicates, here's why the assessment looks this way, and here's what you might want to consider.”
Of course, explaining the idea took considerably less time than building it. That's usually where the fun begins.
The part nobody puts in the hackathon highlight reel
Hackathon stories tend to show the final UI, a clean architecture diagram, a few terminal screenshots, and a team looking suspiciously well-rested.
Our actual engineering experience was a little more realistic.
We had to make decisions about data sources, backend responses, frontend integration, deployment, error handling, and what should happen when something upstream didn't work.
Weather data was available through Open-Meteo, so we could build around a real forecast feed. But when we investigated official IMD warning access, our unauthenticated request to the documented endpoint returned HTTP 401. We couldn't verify the access method and district mapping required for a reliable integration.
Finding trustworthy public water and cooling locations was another challenge. We couldn't establish a reliable, current dataset with appropriate reuse terms.
At that point, we had two options: make the interface look complete with plausible-looking data, or admit what we couldn't verify.
The first option might have made for a prettier screenshot. It would also have made for a less trustworthy product.
We chose the second.
The current implementation explicitly marks official warnings and verified water locations as unavailable rather than inventing warning details or displaying fictional locations.
That decision taught us something important: a missing data source isn't merely a technical inconvenience when people might use your product to make real-world decisions.
“A product should never look more certain than the information behind it.”
We still have work to do before veryHOT.ai can deliver its full heat-and-water vision. But we would rather show that honestly than pretend we've already solved it.
Why AWS became an important part of the build
Once we had the core idea, we needed a backend that could retrieve weather data, process it, and return a structured response to the frontend.
We built the API using Python and FastAPI, then configured our AWS infrastructure using the AWS Serverless Application Model (AWS SAM).
Two AWS services play central roles in the current architecture.
AWS Lambda: running our backend
AWS Lambda runs our Python API handler without requiring us to maintain a continuously running server.
For a student team building within a limited timeframe, this was a practical choice. We could concentrate on the application logic and data flow instead of spending the entire hackathon babysitting a server.
Lambda also provides a foundation for handling requests as usage changes, subject to the limits, configuration, and quotas of the deployed application.
Amazon API Gateway: connecting the frontend to the backend
Amazon API Gateway exposes our HTTP API over HTTPS. It gives the frontend a defined entry point for requesting the forecast and heat assessment.
The frontend doesn't need to know how the backend retrieves and processes the weather data. It requests a response, receives structured information, and presents it to the user.
We also used AWS SAM to define the infrastructure in code. This makes our deployment configuration repeatable and easier to maintain than a collection of undocumented manual steps.
Our data flow looks like this:
User location → Web frontend → Amazon API Gateway → AWS Lambda / FastAPI → Open-Meteo → Heat assessment → Guidance on screen
We added input validation, request timeouts, bounded in-process caching, and structured handling for upstream failures and incomplete data.
These aren't the features that usually make a demo look exciting. Nobody opens a website and says, “Wow, excellent timeout handling!”
But when an external service fails, good error handling is the difference between a product that communicates honestly and one that silently shows misleading information.
AWS gave us a practical way to turn our idea into a deployed backend with a defined architecture. More importantly, it helped us learn how the pieces of a real application fit together.
We weren't just calling an API from a frontend anymore. We were designing, deploying, and debugging a complete request flow.
And yes, there were moments when a single deployment issue felt like it had personally declared war on our deadline.
How We Used AI Tools to Build veryHOT.ai
We used AI as a development partner throughout the project—not as a replacement for engineering decisions.
- ChatGPT — Research & Planning: Used to research the problem space, explore solution approaches, understand AWS services, plan the architecture, and refine the product requirements.
- OpenAI Codex — Coding & Implementation: Used to help implement features, work with the existing codebase, debug issues, and improve the frontend and backend while preserving the project's architecture.
- OpenRouter — Agentic Workflows: Used as an interface for AI models supporting agentic tasks, including development workflows and deployment-related assistance.
The important part was knowing where to use these tools and where human judgment was still necessary. We reviewed implementation decisions, tested the application, and kept data integrity at the centre of the product—especially when official warnings or verified water-location data were unavailable.
Our approach: AI accelerated research and development, AWS provided the cloud infrastructure, and our team remained responsible for the engineering decisions and the final product.
A little appreciation for the people who make building possible
This project was part of a bigger learning experience, and that's where I want to acknowledge the people who made the opportunity meaningful.
First, thank you to Kunal Kushwaha and the WeMakeDevs team for creating opportunities where students can move beyond watching tutorials and actually build something.
As students, it's easy to get stuck in a loop: learn a technology, watch another tutorial, start another repository, and tell ourselves we'll deploy it later.
Opportunities like Environmental Hacks push us to cross that gap between knowing about technology and using it to solve a problem.
I appreciate Kunal's work in building a developer community where learning, shipping projects, and connecting with other builders are central to the experience. Making those opportunities accessible to students is valuable because not everyone begins with the same resources, mentorship, or confidence.
Thank you as well to the AWS team for making cloud technology and learning resources part of the experience. Working with real AWS services gave us a more practical understanding of serverless architecture than simply reading about it could have done.
And to my teammates, Sai Tarun Reddy Velagala, Riteesh, and Dinesh: thank you for the work, the discussions, the debugging, and the effort you put into bringing this idea together.
A project may have one name on the submission form, but getting it to a working state takes a team willing to keep moving when the easy part is over.
We had an idea. We had a deadline. We had bugs that apparently did not know what a deadline was.
And we kept building.
I'm grateful that I got to work on this with you all.
What does “impact” actually mean for veryHOT.ai?
We should be careful about this part.
We haven't conducted a large-scale public pilot, measured a reduction in heat-related illness, or demonstrated that the app has already changed citywide behaviour. Claiming those outcomes would be premature.
Our intended impact is more specific and measurable.
We want to make heat-related information easier to understand and practical precautions easier to find. We want a commuter to understand the upcoming conditions, an outdoor worker to see why taking shaded breaks matters during hotter periods, and a caregiver to have useful forecast context when planning the day.
We want to evaluate whether people can understand our assessment, find the guidance they need, and use the hourly forecast to make better-informed decisions.
That means our next steps are not simply “add more features.”
They include:
- Establish reliable access to official IMD warning data.
- Find and verify credible public water and cooling locations.
- Test the experience with real users in Hyderabad.
- Measure whether users understand the guidance and can retrieve forecasts reliably.
- Improve the product based on what those users actually need.
A feature is not impactful just because it exists. Its value depends on whether it helps someone do something useful.
For veryHOT.ai, the long-term ambition is to help people move from passively checking the weather to actively planning around heat—with the right caveats, credible data, and practical guidance.
We have built the foundation. Now we need to validate how well it serves the people it was designed for.
What this project taught me
If I had to summarise what I learned from veryHOT.ai, it would come down to three things.
Start with a real person. The technology matters, but the person using it matters more. A feature should have a clear reason to exist.
Treat deployment as part of building. A working local prototype is a milestone, not the finish line. Using AWS Lambda, API Gateway, and SAM helped us understand the infrastructure behind a deployed application.
Be honest about what you haven't solved yet. Reliable software isn't software that always has an answer. Sometimes it is software that knows when it doesn't have enough information to answer responsibly.
I'm leaving this project with a working foundation, a better understanding of serverless architecture, and a clearer sense of how much research and validation a real-world environmental solution needs.
And honestly, that feels more valuable than adding ten extra features just to make the README look impressive.
The forecast is a number. The impact is personal.
Hyderabad's heat problem won't be solved by one student project, and we aren't claiming otherwise.
But we believe there is value in making existing weather information easier to understand and act on. If veryHOT.ai helps even one person plan their day with better information, that is a meaningful starting point—and something we can build on through testing and improvement.
Thank you to WeMakeDevs, Kunal Kushwaha, the AWS team, and my teammates Sai Tarun Reddy Velagala, Riteesh, and Dinesh for being part of this journey.
We're proud of what we've built so far, honest about what remains unfinished, and excited to keep improving it.
Because the goal was never to make heat look better on a dashboard.
The goal is to help people make better-informed decisions in the heat.
Explore veryHOT.ai
- GitHub repository: https://github.com/DhanviND360/veryHOT-ai
- Weather data source: https://open-meteo.com/en/docs
- AWS Lambda: https://aws.amazon.com/lambda/
- Amazon API Gateway: https://aws.amazon.com/api-gateway/
- WeMakeDevs Environmental Hacks: https://www.wemakedevs.org/aws/env
Built for WeMakeDevs Environmental Hacks 2026 — Heat and Water track.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article