Beyond the Temperature: Building veryHOT.ai for a City That Knows Heat Too Well
Turning Hyderabad's weather forecasts into practical, locally relevant heat-awareness guidance.
A temperature reading can tell you how hot a day is going to be. It cannot, by itself, tell you how to plan your commute, when to reconsider an outdoor activity, or why humidity might make an already uncomfortable afternoon feel worse.
For a city like Hyderabad, where summer heat is part of everyday life, that distinction matters.
We built veryHOT.ai as our attempt to bridge that gap.
Developed for WeMakeDevs Environmental Hacks 2026 under the Heat and Water track, veryHOT.ai is a Hyderabad-focused web application designed to make weather information easier to understand and use. Rather than presenting another dashboard full of numbers, we wanted to explore how current conditions and forecasts could be translated into practical precautions.
The idea was straightforward. Building it responsibly was considerably more complicated.
Starting with a problem, not a technology
Hackathons make it tempting to begin with a technology stack, an impressive feature, or an idea that sounds good in a presentation.
We wanted to start somewhere else: with a problem that people around us could recognise.
Heat affects people differently. Someone working outdoors has different constraints from someone commuting to college. A delivery partner navigating the city has different needs from a person planning activities for an older family member.
Yet weather applications often leave users to interpret the numbers themselves.
We saw an opportunity to make that process more useful. What if a person could look beyond the temperature and understand the conditions expected throughout the day, why those conditions matter, and what precautions might be worth considering?
That became the foundation of veryHOT.ai.
We deliberately kept the initial scope focused. We wanted to display current weather conditions and hourly forecasts, provide an understandable heat assessment using apparent temperature and relative humidity, and present precautions that relate to those conditions.
We were not trying to solve every problem associated with urban heat in one hackathon. We were trying to build a useful first step towards better-informed decisions.
Turning an idea into a working application
Once we had a clear direction, the challenge became connecting the different parts of the application into something reliable.
Our backend uses Python and FastAPI to retrieve and process weather information. We use Open-Meteo as our weather data provider, with the application requesting current conditions, hourly forecasts, and available daily summaries.
The backend validates location coordinates, processes the returned data, and generates a structured response that the frontend can present to users.
For the heat assessment, we use apparent temperature alongside relative humidity to communicate how the conditions may feel. We also distinguish this supplementary assessment from official weather warnings and medical guidance.
That distinction is important. An application-generated category should not be mistaken for an official alert, and a forecast should not be treated as a guarantee of safety.
We used AWS Lambda to run the backend and Amazon API Gateway to provide an HTTP API entry point. AWS Serverless Application Model (SAM) helped us define and deploy the infrastructure.
This separation gave us a clear flow between the frontend, backend processing, external weather service, and the information ultimately displayed to the user.
It also gave us practical experience with something that tutorials often simplify: getting separate components to work together outside a local development environment.
A feature is not finished just because it works on one developer's machine. Requests can fail, external services can respond unexpectedly, and deployments can introduce problems that never appeared during local testing.
We had to think about those possibilities while building the actual product.
The hardest decisions were not always about code
One of the most important lessons from this project came from the information we could not reliably obtain.
We wanted veryHOT.ai to go beyond forecasts by incorporating official weather warnings and useful water or cooling locations. These features could make the application substantially more useful to someone navigating extreme heat.
However, wanting a feature and having the data required to support it are two different things.
Our attempts to access the documented India Meteorological Department (IMD) warning endpoint encountered an HTTP 401 response. We could not establish a verified access method and the necessary district mapping. Similarly, we could not verify a sufficiently reliable, current public dataset of water and cooling locations with appropriate reuse terms.
That left us with a choice.
We could populate the interface with plausible-looking warnings and locations to make the application appear complete. Or we could clearly communicate that those integrations were not yet available.
We chose the latter.
The application explicitly reports the relevant data as unavailable instead of generating fictional locations or inferring official warnings from forecast conditions.
This was not the most visually impressive outcome for a demonstration. It was, however, the more responsible engineering decision.
When an application may influence someone's real-world decisions, missing information should remain missing information. It should not become invented certainty simply because an empty state looks unfinished.
That principle influenced how we approached the rest of the application, too. We added input validation, request timeouts, bounded caching, and handling for upstream failures and incomplete responses.
Reliability is not just about keeping an application running. It is also about communicating clearly when the application cannot provide a dependable answer.
Building as a team under a deadline
A hackathon compresses the development process into a short period. Ideas, implementation, testing, integration, and presentation all compete for the same limited time.
As the team lead, I had to keep the larger objective in view while we worked through the individual pieces. The challenge was not simply to get features implemented; it was to keep our decisions aligned with the problem we had set out to solve.
That meant repeatedly returning to a few basic questions.
Does this feature help someone make a better-informed decision? Do we have reliable information to support it? Can the application explain what it is showing? What happens when something fails?
Those questions helped us distinguish between features that would make the demonstration look more complete and decisions that would make the product more trustworthy.
The work also reinforced how much coordination matters in software development. A backend response has to match what the frontend expects. Data limitations have to influence the interface. Deployment configuration has to match the environment in which the application runs.
None of these pieces exists independently in a finished product.
I am proud of what our team brought together, but the more valuable part of the experience was learning to approach the application as one connected system rather than a collection of individual features.
Using AI to accelerate development without outsourcing judgment
AI-assisted development was part of our workflow, particularly for research, planning, implementation, debugging, and exploring technical approaches.
These tools helped us move through unfamiliar problems faster. They did not remove the need to understand the resulting code or decide whether a proposed solution was appropriate.
That difference became especially clear when we encountered unavailable data sources.
A model can help write an integration, but it cannot make an inaccessible endpoint accessible or turn an unverified dataset into a trustworthy one. Those limitations require investigation and engineering judgment, not simply another prompt.
Our approach was to use AI to accelerate development while keeping responsibility for the architecture, implementation decisions, testing, and integrity of the information with the team.
For me, that is a more useful way to think about AI-assisted engineering. The objective is not to generate as much code as possible. It is to use the available tools to build something that addresses the intended problem without losing sight of its limitations.
What we have built—and what remains
veryHOT.ai is a working foundation, not a claim that we have solved Hyderabad's heat-related challenges.
The application can present weather forecasts, communicate a supplementary heat assessment, and provide related precautions. The remaining gaps are equally important to acknowledge.
Our next steps include establishing reliable access to official warning data, identifying verified water and cooling locations, testing the application with people in Hyderabad, and evaluating whether users understand and can act on the guidance.
These are not merely additional features on a roadmap. They are necessary steps towards determining whether the application is genuinely useful.
We also need to measure outcomes rather than assume them. Without user testing and meaningful evaluation, we cannot claim that veryHOT.ai has reduced heat-related illness or changed behaviour across the city.
The goal is to reach a point where we can demonstrate what works, identify what does not, and improve the application based on evidence.
The lesson I am taking forward
Working on veryHOT.ai changed how I think about building technology for real-world problems.
It is easy to focus on the visible parts of a project: the interface, the feature list, the architecture diagram, or the final demonstration. Those things matter, but they do not tell the whole story.
The less visible decisions matter just as much. Choosing not to display unverified data. Handling a failed request without misleading the user. Distinguishing an application-generated assessment from an official warning. Recognising that a working prototype still needs validation.
These decisions may not be the features people notice first, but they help determine whether a product deserves to be trusted.
For our team, veryHOT.ai has been an opportunity to take a locally relevant problem, turn it into a working application, and confront the practical challenges that come with building beyond a prototype.
We still have work to do. That is part of the point.
A city cannot become safer in extreme heat because of one student project. But better access to understandable information is a meaningful place to start, provided that information is credible, transparent, and useful.
The objective behind veryHOT.ai is simple: help people move from knowing that it is hot to making better-informed decisions about what to do next.
That is the problem we set out to explore, and the standard we want to keep building towards.
Built for WeMakeDevs Environmental Hacks 2026 — Heat and Water track.
Thanks to WeMakeDevs, Kunal Kushwaha, the AWS team, and my teammates for making this project and the learning experience possible.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article