Building MonsoonReady AI
The problem
Heavy rainfall can cause urban waterlogging and flooding that disrupt travel, damage property, and create risks for communities. When incident information is scattered or difficult to organize, response teams may struggle to identify which reports need attention first.
I started building MonsoonReady AI to explore how software can help organize water-related incident reports and support risk-based prioritization.
What the project does
MonsoonReady AI is a web application designed for communities, local authorities, and emergency response teams.
Its main features include:
- Incident reporting: Record information such as location, water depth, and severity.
- Priority calculation: Use risk factors to help identify incidents that may require urgent attention.
- Centralized dashboard: View, search, and filter incident reports.
- Status updates: Update an incident as its status changes.
- Persistent storage: Retain report information across page refreshes.
- Weather fallback: Handle unavailable external weather data without breaking the local demonstration.
The goal is to make incident information easier to organize and help users make more informed decisions.
Technology and architecture
The frontend is built with React, TypeScript, Vite, and Tailwind CSS. The backend uses FastAPI and SQLite for the local demonstration.
The project also contains a separate Lambda-compatible priority function and an AWS Serverless Application Model (AWS SAM) template intended to describe the serverless component.
Keeping the priority logic separate makes it possible to compare its behavior with the backend implementation.
Exploring AWS and serverless design
AWS Lambda provides a potential way to run incident-priority processing independently from the main web application. AWS SAM offers a template-based approach to defining serverless resources.
During development, I used a local comparison script to check that the Lambda-compatible priority logic produces matching results to the backend implementation.
Current limitation: The verified workflow runs locally. I have not yet confirmed a live AWS Lambda invocation, a successful Amazon S3 upload, or a deployed cloud environment. SAM validation was blocked by a local Python compatibility issue. These remain areas for further implementation and testing.
I believe documenting these limitations is an important part of responsible engineering: a component designed for AWS is not the same as a component already deployed and verified on AWS.
Challenges and lessons learned
One of the main challenges was separating application logic from environment and deployment issues. Local application tests, matching priority outputs, and a successful frontend build provide useful evidence, but they do not replace testing a cloud deployment.
This project helped me learn about:
- Building a full-stack application with React and FastAPI.
- Designing a risk-priority workflow for incident reports.
- Comparing separate implementations through automated tests.
- Exploring AWS Lambda and AWS SAM.
- Handling external-service failures gracefully.
- Clearly distinguishing implemented features from unverified integrations.
What's next?
The next steps are to validate the SAM template in a compatible environment, verify the AWS integration, test cloud storage if enabled, and evaluate the system using realistic incident scenarios.
MonsoonReady AI is a prototype, not a replacement for official emergency services. Its purpose is to explore how organized reporting and transparent prioritization could support better incident management during heavy rainfall.
Conclusion
Building MonsoonReady AI has been an opportunity to connect full-stack development, risk-based decision support, and serverless architecture around a real-world problem.
The project is an ongoing learning experience, and the next milestone is to validate the AWS components in a real environment and measure how effectively the application supports incident-management workflows.
Loading article