DrainWatch: Community Drainage & Cleanup Planning

Turning scattered drainage reports into an explainable priority map and a cleanup plan optimizer, so communities can act before the next flood, not after.

Comment

Inspiration

Blocked drains and standing water are a constant, low-visibility problem in many communities — but reports about them usually disappear into a WhatsApp group, a phone call, or a forgotten form. Nobody can see where the problems are clustered, and when maintenance teams do have time or budget, there's no clear way to decide which sites to fix first. As rainfall patterns become more extreme, that gap between "someone noticed a problem" and "someone with authority can act on it" becomes a real flood and public-health risk. DrainWatch exists to close that gap: turn scattered observations into a transparent, explainable plan.

What it does

DrainWatch is a community drainage reporting and cleanup-planning prototype with three parts:

  • Reporting: anyone can submit a drainage observation (location, blockage level, standing water, nearby buildings) through a simple form.
  • Explainable priority scoring: the backend calculates a 0–100 priority score from the reported conditions using fixed, published rules (not a black box), and classifies it High/Medium/Low. An interactive map shows priority-colored markers so patterns are visible at a glance.
  • Cleanup Planning Lab: the part we're most proud of. Given a limited cleanup budget, it compares two selection strategies side by side: highest-priority-first versus an exact 0/1 knapsack algorithm that maximizes total blockage removed for the same effort. Users can edit effort estimates, run a fictional example, and export a comparison brief, all without altering the saved reports.

The goal isn't to predict flooding, it's to make triage decisions visible and defensible when resources are limited, which is the real bottleneck for most community maintenance teams.

How we built it

  • Frontend: React + Vite, Tailwind and custom CSS, React Leaflet for the interactive map, deployed on Vercel.
  • Backend: FastAPI + Pydantic + SQLAlchemy, deployed as a Docker container on Northflank, backed by PostgreSQL in production (SQLite locally).
  • Planning algorithm: a from-scratch 0/1 knapsack implementation in the frontend, validated against exhaustive subset search.
  • Spam/abuse protection: duplicate-submission detection (normalized text + 6-decimal coordinate matching), a shared rolling-window rate limit, a hidden bot-trap field, and request-size limits -implemented and tested, not just planned.

Challenges we ran into

  • Designing a scoring system that's genuinely reproducible and explainable, rather than a hidden formula, every score had to be traceable to the three reported conditions that produced it.
  • Getting the knapsack-based planner correct under edge cases (ties, empty plans, invalid estimates), this required writing a dedicated test suite (10 tests) that checks agreement with exhaustive search across 780 fixture/budget combinations, not just spot-checking a few examples.
  • Building basic but real abuse protection (duplicates, rate limits, bot traps) without a full auth system, since the app needed to stay open to anonymous community reporting.
  • Being honest in the UI and docs about what the scores are (and aren't), they're review priorities based on unverified reports, not flood-risk predictions, and the app says so explicitly rather than implying more certainty than it has.

Accomplishments that we're proud of

  • A fully deployed, working full-stack app (not a mockup), frontend, backend, and database all live and talking to each other.
  • The Planning Lab's algorithm is independently validated: 10 passing tests, agreement with exhaustive search across 780 scenarios, and 8 passing backend integration tests covering persistence, scoring, validation, quotas, duplicates, and concurrency.
  • Real submission safeguards (duplicate detection, rate limiting, bot-trap field, size limits) that were actually tested, not just described.

What we learned

Building the Planning Lab meant implementing and testing a 0/1 knapsack solver from scratch and proving it against brute-force search rather than trusting it "looked right" - a good lesson in how much testing infrastructure is worth for anything doing nontrivial computation. We also learned a lot about the gap between "a feature works" and "a feature is defensible", writing the assumptions and limitations directly into the README (e.g., that reports aren't verified, that scores aren't flood-risk predictions) turned out to be as important as the feature itself.

What's next for DrainWatch

  • Group nearby observations so multiple reports of the same physical site don't get double-counted.
  • Add a moderation/verification workflow so maintenance teams can confirm reports before they drive planning decisions.
  • Calibrate effort estimates and scoring against real maintenance-team feedback instead of illustrative defaults.
  • Expand PostgreSQL integration tests and do a full mobile/accessibility pass.

Built With

Share this project:

Updates

Submission history