INDRA: Because Apparently, India Can Have Too Much Water and Too Little at the Same Time

What if the water flooding our streets today could help us deal with water scarcity tomorrow? This is the story of building INDRA, a climate-resilience platform that connects climate data, rainwater harvesting, and AI to help people make more informed decisions about water.

Suravi Jha

Published Oct 11, 2026

Last modified Oct 11, 2026

﻿
Every monsoon, we talk about flooding. A few months later, we're talking about water scarcity. Somehow, both can be problems in the same country, sometimes even in the same region. Which got me thinking: we spend a lot of time discussing how much rain we get, but considerably less time connecting that information to what people can actually do with it.
That was the starting point for INDRA (Initiative for Drainage and Rainwater Acquisition), a project I built around a question that sounds simple enough: can we use climate information to help people make better decisions about water, rather than just tell them that there's a problem?
Before writing code, I had to figure out what was already being done.I started by looking into India's existing water-management efforts. NITI Aayog's Composite Water Management Index examines how states manage water resources, including groundwater, irrigation, restoration of water bodies and urban water supply. The Central Ground Water Board also provides guidance on rooftop rainwater harvesting, groundwater recharge and related interventions. Meanwhile, weather services provide rainfall forecasts and warnings.
So the problem wasn't that nobody was collecting data or proposing solutions. There was already plenty of work happening in these areas. What interested me was the gap between knowing the situation and deciding what to do about it.
A rainfall warning doesn't calculate how much water your roof could collect. A rainwater-harvesting guideline doesn't automatically tell you what tank your house needs. And a farmer deciding what to plant has a very different set of questions from an apartment society trying to reduce its dependence on external water supplies.
I didn't want to build another dashboard that showed a few impressive graphs and left users to figure out the rest. I wanted to connect the information to actual decisions.
That narrowed the idea down considerably: assess the risk, estimate the available water, and help the user decide what to do next.
The ideation: one problem, several very different people
﻿
﻿
The first challenge was deciding who INDRA was actually for. Initially, the idea of a general water-management platform sounded reasonable, but the more I thought about it, the less sense a one-size-fits-all interface made.
A household might want to know whether rainwater harvesting is feasible, how much it would cost and how much water it could collect. A farmer would care more about water availability, crop requirements and groundwater stress. A village council might need to think about community-level demand instead.
I could have built separate applications for all three. That would also mean maintaining separate systems for problems that share a lot of underlying information.
Instead, I decided to build two experiences around one climate engine: Urban mode for households and apartment societies, and Gramin mode for farmers, cattle owners and village councils. The calculations and climate-risk information could be shared, while the interface and recommendations would change according to the user.
This decision also gave the project a clearer scope. Rather than trying to solve every water-related problem in India, I could focus on connecting climate risks to practical interventions, starting with rainwater harvesting and water planning.
Then came the part where the data had to make sense.
﻿
﻿
INDRA needed to assess flood, water-scarcity and heat risk across 754 districts and approximately 19,000 pincodes. I wanted these risks to remain distinct because a single overall score could conceal important differences. A district facing intense rainfall and one facing groundwater depletion need different responses, even if their combined scores happen to look similar.
I also wanted to identify places where both flood and scarcity risks coexist. This became the swing index: an attempt to highlight districts where receiving water and having reliable access to it are two very different things.
While developing the climate engine, I ran into a less glamorous problem than designing a new index: the data itself. An existing processed dataset contained normalised rainfall and groundwater values, with missing rainfall filled using a global median. Those values weren't suitable for calculations that needed actual rainfall measurements. A mathematically correct formula using the wrong units is still going to give you a useless answer.
I rebuilt the dataset around real values, added estimates for districts without observations using the three nearest observed districts, and tracked the provenance of the data. It wasn't the flashiest part of the project, but it was necessary. There isn't much point building a sophisticated recommendation system if its inputs don't represent reality.
From "it's going to rain" to "here's what your roof could do"
﻿
Rainwater harvesting became one of the clearest ways to turn the idea into something concrete. The basic calculation is straightforward: roof area multiplied by rainfall and a runoff coefficient gives an estimate of harvestable water.
For example, a 100 m² RCC roof receiving 1,000 mm of annual rainfall, with a runoff coefficient of 0.8, could theoretically collect around 80,000 litres a year. That's a useful estimate, but it doesn't mean the household will have 80,000 litres available whenever it needs them. Rainfall timing, storage capacity and collection losses all matter.
That's why INDRA goes beyond the annual estimate. It calculates indicative tank requirements and costs, checks feasibility, and considers alternatives such as recharge pits. It also accounts for physical constraints: recommending a heavy rooftop tank without considering the roof structure would be a rather expensive way to demonstrate that software doesn't understand buildings.
The next question was how to make these recommendations understandable to someone who doesn't want to spend their evening learning hydrology. That meant using plain language, familiar units and a visualizer that helps users explore the proposed setup rather than expecting them to interpret raw calculations.
I also wanted users to be able to ask questions about the recommendations. Naturally, that led to AI, and naturally, AI introduced its own problems.
Giving AI a job it can actually doI didn't want a chatbot inventing tank sizes or producing a different water estimate from the calculator. Those calculations needed to be consistent and reproducible, so I kept the numbers in deterministic application logic and used AI for explanation and information retrieval.
For the retrieval system, I processed 16 technical PDFs into 2,447 chunks, generated MiniLM embeddings and indexed them using OpenSearch. The Strands-based assistant can access climate-risk information, call the roof-sizing logic and search technical documents for relevant guidance.
I also built fallback paths so the application wouldn't become useless if the external AI service failed. The agent can fall back to plain document retrieval and then to an offline, grounded answer. The core calculations remain independent of the language model.
This was an important design choice for me: adding AI should make the application more useful, not make every other part of it dependent on AI behaving perfectly.
The same principle guided the rest of the project. I added a Java telemetry service to estimate how quickly a tank is filling or emptying from recent readings, along with a scheduled alert pipeline that checks subscribed districts and sends relevant notifications. These components extend the platform from assessing what might happen to helping users monitor conditions and receive updates.
And then I had to test whether any of this actually worked.A project can have a convincing interface, a long list of technologies and a chatbot that gives excellent demonstrations. None of those things proves that the underlying system is reliable.
I wrote tests across the climate engine, backend, serverless components and Java service. The project currently has 135 automated tests, alongside frontend checks and deployment-manifest validation. I also tested the agent, Cedar policy rules, serverless logic against an in-process AWS emulator, and the OpenSearch fallback.
There are limits to what I verified, and I don't want to pretend otherwise. Some deployment targets, including container images, Kubernetes application, SAM execution, the LocalStack container and Firecracker boot, were statically validated rather than fully executed because the necessary tooling or system support wasn't available on my development machine.
I also found that some source data is less precise than the recommendations would ideally require. Groundwater information is available only at state level in parts of the dataset; crop prices are indicative averages, and some estimates rely on heuristics. These are limitations that need better data and real-world validation, not prettier UI components.
That leaves plenty to do: connect affordable tank sensors, improve local data, verify vendors and subsidy information, and test the recommendations with actual households and communities. A working application is a start, not proof that it has improved water management.
So, what did I learn from building INDRA?The biggest challenge wasn't implementing a calculator, integrating a language model or getting the frontend to work. It was figuring out how to connect information that usually lives in separate places without pretending that one application can solve every underlying problem.
INDRA brings together climate-risk assessment, rainwater harvesting, water planning, technical-document retrieval, telemetry and alerts. The point isn't that it has all these features. It's that each one supports the same goal: helping users move from understanding a water problem to evaluating what they can do about it.
There's still a substantial gap between a software prototype and a system that communities can rely on, and closing it will require better data, real-world testing and feedback from the people using it.
But I think the question behind the project is worth pursuing. We can't control when the rain arrives, and we can't solve water scarcity with a dashboard. We can, however, make better use of the information we already have and make it easier to evaluate practical interventions.
And honestly, if we're going to spend one part of the year trying to get rid of water and the other trying to find it, we should at least get better at planning for both.