DeFlood.AI

From flood risk to action: DeFlood.AI assesses local risk, creates AI-assisted evacuation plans, and coordinates support requests, all in one workflow.

Comment

Inspiration

Myanmar has always been highly vulnerable to flooding, and every year we see the same pattern: heavy rain, rising rivers, flood warnings, evacuations, damaged homes, and communities needing help.

That made us wonder about something.

If warnings already exist, why do people still struggle so much when floods happen?

We realised that knowing a flood may happen is only the beginning. A warning does not necessarily tell a village leader who should evacuate first, whether there is enough shelter, whether there are enough vehicles or boats, or how a community should communicate that it needs help.

There was a gap between knowing there is danger and knowing what to do about it.

That became the idea behind DeFlood.AI.

We wanted to build something that did not just show another weather forecast or another warning, but helped turn information into actual decisions.

Our idea eventually became:

ASSESS → PLAN → COORDINATE

Understand the risk. Decide what to do. Communicate where help is needed.

What it does

DeFlood.AI is a flood preparedness and decision-support prototype built around three connected parts.

1. ASSESS

DeFlood uses environmental information such as location, rainfall forecasts, river discharge, and elevation to assess local flood risk as:

LOW, MEDIUM, or HIGH

We intentionally do not let the language model decide the flood-risk level. The risk assessment is handled using transparent rules so that the result is easier to understand, test, and explain.

2. PLAN

A flood-risk level alone is not enough to make an evacuation decision.

Two communities could both be at HIGH risk while having completely different situations.

One may have enough shelters, boats, and volunteers, while another may have almost none.

DeFlood therefore also considers community information such as:

  • population
  • children
  • elderly residents
  • people with disabilities
  • shelter capacity
  • vehicles
  • boats
  • volunteers

Normal code handles calculations such as shelter shortages.

The AI then receives the structured risk and community information and generates an evacuation recommendation containing things such as:

  • urgency
  • priority groups
  • immediate actions
  • resource warnings
  • missing information

This led to one of the main principles behind our project:

Code calculates. AI reasons. Humans decide.

3. COORDINATE

We also wanted DeFlood to address what happens when a community actually needs outside assistance.

Our Support Network uses different prototype views for communities, NGOs, and government coordinators.

A community can submit an assistance request with information such as its location, the number of people needing help, vulnerable groups, the type of assistance needed, and a short description.

NGO and government views are designed around reviewing those needs rather than showing every user the same dashboard.

The current prototype demonstrates these role-specific workflows locally. A future version would connect authorized communities and organizations through a shared backend so that the same requests could be accessed across different devices in real time.

DeFlood is not intended to replace emergency authorities. It is meant to help organize information so that people can make clearer decisions.

How we built it

We built DeFlood.AI as a React-based web application.

For the environmental side, we searched for data sources that were accessible enough for a student project while still giving us meaningful real-world information.

We eventually integrated multiple environmental sources, including:

  • ECMWF IFS weather forecasts
  • ECMWF AIFS AI weather forecasts
  • GloFAS river-discharge forecasts
  • elevation data
  • browser GPS location

Instead of relying on one source alone, we experimented with combining multiple signals into our own flood-risk logic.

For the evacuation planner, we used n8n to create the AI workflow and connected it to a Groq-hosted language model.

Getting that workflow to communicate with an actual deployed website was one of the more interesting parts of the project. During development, we were running n8n from a Windows computer and had to learn how webhooks, tunnels, and Cloudflare could connect our local workflow to the public DeFlood website.

We also spent a lot of time deciding what the AI should not do.

Rather than giving the model everything and asking it to make every decision, we separated the system into different responsibilities:

Environmental data → Risk logic

Community data → Capacity calculations

Risk + capacity → AI evacuation planning

Assistance requests → Support Network

That architecture changed quite a lot from our earliest version of DeFlood.

Challenges we ran into

One of our biggest challenges appeared very early:

"How is this actually different from other flood apps?"

At first, we focused heavily on flood prediction and risk.

But the more we worked on the project, the more we realised that weather services and flood-warning systems already exist.

Trying to compete by simply producing another prediction did not feel meaningful. That made us doubt our own project until the point of nearly dropping the idea.

But as not much time was left, that question forced us to rethink DeFlood.

We moved our focus from only asking:

"Will there be a flood?"

to asking:

"If this community is at risk, what should they do next?"

That change is what led to the evacuation planner, community-resource analysis, vulnerable-group prioritisation, and eventually the Support Network.

Another challenge was environmental data itself.

Real APIs are not perfect. Different forecasting models can disagree or be unavailable. River-discharge information does not always map perfectly to the exact community we want to assess.

We originally wanted to make some much stronger claims about flood mapping and prediction, but working with the real data taught us to be more careful.

Instead of pretending that DeFlood can predict the exact streets that will flood, we decided to present it honestly as a local flood-risk assessment using multiple environmental signals.

We also struggled with where AI belonged in the system.

It would have been much easier to simply send all the numbers to an LLM and ask it to decide everything.

But we realised that things like:

2,000 people - 1,200 shelter spaces = 800 people without shelter capacity

do not need AI.

They need reliable code.

The AI becomes useful after those facts are known, when the system needs to interpret the situation and turn it into a clear recommendation.

There were also plenty of normal development problems: APIs not behaving the way we expected, workflows failing, connecting n8n to the deployed frontend, changing parts of the interface, and repeatedly narrowing features that were too ambitious for the prototype.

Sometimes improving DeFlood meant adding something.

Other times it meant admitting that a feature was not realistic yet and removing it.

Accomplishments that we're proud of

One thing we are particularly proud of is that DeFlood became much more than the idea we started with.

We began with a fairly simple concept around flood risk.

By the end, we had connected several parts into one workflow:

environmental data → flood-risk assessment → community capacity → AI-assisted evacuation planning → support coordination

We successfully integrated real environmental data sources instead of building the entire demonstration around fake values.

We also connected our n8n AI workflow to the actual web application, which was something none of us had done before.

Another accomplishment we are proud of is actually choosing not to use AI for everything.

During an AI competition, it can be tempting to make every feature AI-powered.

Instead, we tried to use AI where we felt it actually added value.

Risk calculations and resource shortages are handled using normal logic. The language model focuses on reasoning, prioritisation, and explaining the situation.

That decision eventually became:

Code calculates. AI reasons. Humans decide.

We are also proud of how much the project changed after we challenged our own original idea. The question of why DeFlood should exist alongside existing flood tools initially felt like a weakness, but answering it eventually became one of the most important parts of the project.

What we learned

We learned a lot of technical things while building DeFlood, from working with external APIs to React, webhooks, n8n, Cloudflare, and integrating an AI workflow into a deployed application.

But probably the biggest lesson was that building an AI project is not about putting AI everywhere.

Sometimes normal code is the better tool.

Sometimes the data is not reliable enough to make the claim you originally wanted to make.

And sometimes a feature that sounds impressive on paper is less useful than a much simpler feature that solves a real problem.

We also learned how much product design changes once you think about different users.

A village leader does not need the same interface as an NGO coordinator.

An NGO does not need the same information as a government coordinator.

Thinking through those roles pushed us to stop treating DeFlood as one dashboard and start thinking of it as a system connecting different decisions.

Most importantly, we learned that our first idea did not have to be our final idea.

DeFlood improved because we kept asking what was realistic, what was actually useful, and what we could honestly demonstrate.

What's next for DeFlood.AI

The version we built for the competition is still a prototype.

One of our biggest next steps would be turning the Support Network from a local demonstration into a genuinely connected system.

Instead of switching between Community, NGO, and Government views on one prototype, a future version could use a shared backend with authenticated accounts so that authorized organizations and communities could access the same requests from different devices.

We would also like to explore:

  • stronger testing of our risk logic using real flood events
  • better hydrological and geographic data
  • larger shelter and community-resource datasets
  • cross-device support-request coordination
  • notifications when important conditions change
  • SMS support for areas with limited internet access
  • partnerships with NGOs, communities, and relevant authorities
  • validation of evacuation recommendations with people who have real disaster-response experience

Our long-term goal is much bigger than winning a competition.

We would like DeFlood.AI to eventually become something that could genuinely help people make better decisions when those decisions matter most.

Flood data can tell us what may happen.

We built DeFlood.AI to explore what should happen next.

Share this project:

Updates

Submission history