The tool starts with a baseline scenario and tests what happens when we clear each blocked drain individually.
The Water tab also shows where the rain goes: water carried away by drains, water stored in the pits etc

Inspiration

Urban flooding is often discussed in terms of how much rain falls, but what happens on the ground also depends on how effectively a neighbourhood can drain that water. When heavy rain arrives and drains are blocked, water can accumulate on streets, and maintenance resources may not be enough to address every problem at once.

I wanted to explore a practical question: when not every drain can be cleared immediately, how can a community identify which intervention deserves attention first?

That question became One Drain Away. I wanted to build something around a meaningful real-world problem, learn by translating it into a working model, and explore how software can help people reason about possible solutions. Rather than adding AI simply for the sake of using it, I wanted the project to demonstrate how a concrete problem can guide the technology being built.

My initial audience is a neighbourhood residents' association (RWA) secretary or community volunteer trying to understand local drainage concerns, with ward engineers as a secondary audience who may find the scenario comparisons useful.

What it does

One Drain Away is an interactive, simulation-based urban drainage planning tool set in an invented neighbourhood called Shanti Nagar.

It lets users: Simulate rainfall and observe water accumulation across streets. Rank both blocked-drain clearance candidates and working drains that may be important to protect. Compare the simulated outcome before and after a single intervention. Clear multiple blockages and explore their combined effects. Inspect the model's water balance. Generate a planning report summarising the scenario and candidate interventions.

The central interaction is simple: change one thing, observe what happens, and compare the alternatives before deciding what to investigate.

An important finding in the default scenario is that the strongest candidates to protect can have larger simulated effects than the individual blocked drains that could be cleared. That distinction matters: maintenance decisions are not only about which blockages to remove, but also about which functioning parts of the drainage network may be important to preserve.

How we built it

I built One Drain Away as a browser-based simulation using HTML, CSS, JavaScript and Canvas 2D, with Node.js tests for the simulation logic. It runs locally without a backend, external APIs or paid services.

I used an AI coding agent as part of my development process. The initial prototype came first. I then used a plan-first skill pack to review the existing project, refine the scope, write and review the requirements, and specify what the finished implementation should do. I used that plan to guide the final improvements and check the app against the intended behaviour. I also tested the main interactions hands-on and reviewed whether the results and explanations were presented clearly.

Challenges we ran into

One of the biggest challenges was turning a complex physical problem into a simplified model that still produces useful comparisons.

During development, I found a modelling issue involving water moving back and forth between cells in flat basins. I corrected the flow behaviour by capping the flow rate. That changed the baseline result, reinforcing an important lesson: a simulation can look convincing while its underlying behaviour still needs careful investigation.

Another challenge was understanding how interventions interact. The effect of clearing several drains together is not necessarily the sum of their individual effects, so the combined scenario needs to be simulated rather than inferred by adding up separate results.

I also had to think carefully about how to communicate rankings. A candidate that performs well in a model is a useful starting point for investigation, but the meaning of that result depends on the scenario and the assumptions behind the simulation. I wanted the interface to encourage exploration rather than present a ranking without context.

Accomplishments that we're proud of

I'm proud that I turned a practical urban-flooding question into a working simulation that users can experiment with rather than just read about.

In the illustrative default scenario—rainfall of 40 mm/hour for 60 minutes—the baseline result is 1,764 flooded street-minutes. This metric counts each street cell holding at least 50 mm of water for each simulated minute; a lower value means less accumulated street flooding in the model.

Clearing the top-ranked blocked-drain candidate, D17, reduces the result from 1,764 to 1,124, a reduction of 640 simulated flooded street-minutes. Clearing all five blocked drains produces a result of 788, a reduction of 976 from the baseline.

The combined result reveals something more interesting than the final number alone: the five individual clearance scenarios have savings totalling 1,192 street-minutes, but clearing all five together saves 976. The difference comes from overlapping effects: D36, D37 and D38 serve the same hollow, so their individual savings are not additive. This shows why combined interventions need to be simulated rather than estimated by simply adding individual results.

I'm also proud of the distinction between clearing and protecting. In this scenario, some working drains rank highly by the simulated increase in flooding when they are blocked. That helps turn the tool into more than a list of maintenance candidates: it also invites users to consider which functioning infrastructure should be protected.

These results are from an illustrative model, not a validated forecast of real-world flood outcomes. What I'm proud of is having a working, tested environment in which the assumptions and interventions can be explored and compared.

What we learned

Building the prototype taught me that a simulation can look convincing while still producing misleading results if its underlying rules are not sound. I encountered water moving back and forth between cells in flat areas and corrected the flow behaviour before relying on the results.

The combined-clearance results taught me that interventions can overlap: D36, D37 and D38 serve the same hollow, so their individual savings cannot simply be added together to predict the combined result.

Checks across different rainfall intensities and flood thresholds showed that D17 remained the top clearance candidate across the tested scenarios, even as the overall totals changed. That reinforced the value of examining the relative ordering of interventions alongside their simulated impact.

I also learned to use AI-assisted development as an iterative process: build, inspect, test, revise, and verify against explicit requirements rather than assuming generated code is correct. Reviewing the existing prototype against a written plan gave me a concrete way to evaluate the final result.

What's next for One Drain Away

My next goal is to move from an illustrative neighbourhood towards a model informed by real conditions.

That would mean exploring local drainage-network data, terrain and elevation information, rainfall observations or forecasts, and historical flooding records. I would also want to compare the simulation's results against observed outcomes and work with domain experts to evaluate its assumptions.

With that foundation, I could investigate maintenance planning across multiple storms, evaluate combinations of interventions, and explore how limited maintenance resources might be allocated more effectively.

The long-term ambition is to develop One Drain Away into a practical decision-support tool for communities and urban drainage teams. The current prototype is an early step towards that goal: a way to explore interventions, test ideas, and learn what evidence is needed to make such a tool useful in real-world decisions.