ClimateShield: From Climate Risk to Action — Building an Urban Resilience Platform
ClimateShield is an urban climate-resilience platform designed to connect heat and water risks with practical, evidence-informed action. In this article, we explore how we are building the platform, integrating verified reservoir observations for Ahmedabad's (for test purpose) water-supply and heat context, connecting all the components, and developing risk-assessment and intervention workflow. We also share the challenges, technical decisions, and lessons shaping our journey toward more resilient cities.
Why We Started Building ClimateShield
When we started thinking about which PS to take with the given theme, we thought about heat and air and then realized that urban climate problems are not limited to a single hazard. A city can experience extreme heat, face pressure on its water supply, and struggle with waterlogging during heavy rainfall ---> this pushed us to start building ClimateShield as a solution to the thought problem.
The challenge is not just identifying these problems. It is understanding the information available, recognizing which risks need attention, and determining what action might help.
This was the actual motivation behind ClimateShield. We wanted to explore how software could connect climate-related information with risk assessment and intervention planning in one platform.
Our focus is on building something that goes beyond displaying numbers: a system that helps users understand the situation and make better-informed decisions.
So you all must be thinking what actually is Climate Shield, read the next section to know more about it and what it actually does.....
What Is ClimateShield?
ClimateShield is our attempt to connect urban climate-risk information with practical decision support.
The platform brings together a frontend dashboard, backend processing and specialized application logic. Its intended workflow is to help users explore available information, understand relevant climate and water risks, and identify suitable responses.
One of the important parts of our implementation is the water and heat intelligence component, which we have been developing around reservoir observations relevant to Ahmedabad's water-supply context (we chose Ahmedabad as it is more prone to both heat and flood issues, also the data is available and is more accurate :)).
Beyond the water and heat component, the broader project is designed to support climate-risk assessment and intervention planning. Our goal is to make the relationship between a risk and its recommended response easier to understand.
How We Structured the Application:
We approached ClimateShield as a connected application rather than a collection of isolated screens.
The frontend is responsible for presenting information and handling user interactions. The backend connects those interactions to the application's processing logic. Individual engines handle their respective calculations or risk-assessment tasks.
This separation makes the application easier to understand and maintain. It also means that integration matters: the frontend, backend, data inputs and processing functions must work together for a feature to be useful.
During development, one of our priorities has been understanding the complete path from a user action to the result displayed on the dashboard.
Moving Beyond Risk Indicators
A dashboard can tell a user that a problem exists, but that information is more useful when it helps them understand the available responses.
This is the idea behind ClimateShield's intervention workflow. We want to connect risk-related information with recommendations that users can review and act upon.
For example, water-supply pressure could lead to conservation measures, while a flood-related concern could prompt drainage inspections or emergency preparedness.
The engineering challenge is ensuring that recommendations are not disconnected from the underlying assessment. A user should be able to understand why a particular advisory appears and which conditions or inputs support it.
Our next priority is to validate this complete workflow: from selecting a scenario, through backend processing, to displaying the appropriate advisory in the frontend.
Testing and Lessons Learned: Making ClimateShield Work as a Connected System
Building ClimateShield taught us that implementing individual features is only one part of developing a reliable application. A dashboard can render correctly, a backend endpoint can exist, and a processing engine can run independently, yet the complete feature may still fail when these components are connected.
For a climate-resilience platform, this distinction matters. Information must travel through the application correctly, calculations must use appropriate inputs, and the results must be communicated clearly to the user. We therefore approached testing as a way to examine the complete path from data input to the final result displayed on the dashboard.
1. Investigating an Integration Issue
One of the important areas we focused on during development was the connection between user interactions, backend processing, and the information displayed by the frontend.
The issue we investigated: [Describe one bug that you actually encountered.]
We initially expected a merge conflict free process. However, during testing, we faced so many merge conflict and error which took hours to solve and roll back to working version taking whole night and led us to stay awake for countless hours
Rather than assuming that the problem originated in the user interface, we broke the workflow into smaller stages. We examined whether the frontend was sending the expected request, whether the backend was receiving the correct inputs, whether the relevant processing function was being called, and whether the response was returned and displayed correctly.
This helped us narrow the investigation to issue and solve it, also a huge shoutout to ANTIGRAVITY without which we couldnt have made this much errors😭 and yes, we couldnt have made this project without it, So really a great tool for us developers
What we learned: Testing a feature in isolation is not sufficient when its behaviour depends on multiple connected components. Tracing a request from the interface through the backend and back to the user-facing result provides a more systematic way to identify integration problems.
Evidence to add: Include a screenshot of the original error, a relevant code change, or a test result showing the behaviour before and after the fix.
Conclusion: Building Toward More Resilient Cities
ClimateShield represents our effort to connect climate-risk information with practical, evidence-informed action. Through its connected application architecture, water-data integration, risk-assessment capabilities, and developing intervention workflows, we are working toward a platform that helps make complex urban challenges easier to understand and address.
Our journey has also taught us that meaningful climate technology requires more than an attractive dashboard or a working algorithm. It depends on trustworthy data, transparent assumptions, reliable integration, and careful testing. Every improvement to these foundations brings us closer to a system that users can understand, evaluate, and potentially use to support better decisions.
We see ClimateShield as an evolving project, with opportunities to strengthen its data pipelines, validate its risk assessments, improve its advisory workflows, and expand its deployment capabilities using suitable cloud services.
Ultimately, our vision is simple: move beyond identifying climate risks toward helping cities prepare, respond, and build resilience. ClimateShield is one step in that direction, and we look forward to continuing to learn, test, and improve as we build technology for a more climate-resilient future.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article