The Water Was There. The Plan Was Missing.
How we built ReFlow, a water reuse planning prototype using AWS Amplify Gen 2, Amazon Cognito, Lambda, and SES—and what we learned about connecting water planning, usage records, and cloud services.
Student
The Water Was There. The Plan Was Missing.
Building ReFlow: a water reuse planner with AWS Amplify, Amazon Cognito, Lambda, and SES.
Water scarcity is often described as a supply problem. We need more water, better infrastructure, and more efficient systems. But there is another question worth asking: how much treated water could we reuse if we planned for it better?
That question became the starting point for ReFlow, our project for Environmental Hacks — Bharat Builds Tour, built by TechZen.
ReFlow is a water reuse planning application designed to help building staff plan treated-water allocations, record actual usage, and understand how much freshwater could potentially be replaced.
Our idea was simple: give every drop a second chance. Turning that idea into a working prototype taught us about data modelling, authentication, cloud architecture, and the difference between displaying a number and making that number meaningful.
Part one: treatment is only the beginning
Wastewater can pass through screening, settling, biological treatment, filtration, and disinfection. When the resulting water meets the appropriate quality requirements, it may be suitable for non-drinking purposes such as landscaping or toilet flushing.
But treatment alone does not guarantee effective reuse.
A building still needs to know how much treated water is available, which uses are suitable, how much each use requires, and how actual consumption compares with the plan.
Without a clear way to organize this information, it becomes harder to understand where treated water could replace freshwater.
We wanted to explore this planning gap. Instead of building another general sustainability dashboard, we focused on a practical workflow: plan reuse, record consumption, and review the results.
Part two: designing ReFlow around the workflow
We named the application ReFlow, with the tagline “Give Every Drop a Second Chance.”
The Plan section begins with the volume of treated water available for reuse. Users can define suitable non-drinking needs, including toilet flushing, landscaping, and floor cleaning, and enter the required litres for each.
ReFlow calculates recommended allocations based on the available volume and selected demands. Users can then record actual water usage and review saved entries in Records.
The Insights section brings recorded information together through charts and summaries.
For example, the demonstration dashboard displays treated water delivered, freshwater replaced, and a freshwater replacement rate. Users can also switch between seven-day and thirty-day views to examine the recorded information over different periods.
These numbers have different meanings. Planned allocation is not actual consumption, and estimated freshwater replacement is not the same as independently measured environmental savings.
Our current prototype uses recorded demonstration data rather than live sensor readings. We made this distinction explicit because a useful sustainability application should help users interpret information, not imply that estimates are verified measurements.
Part three: connecting the frontend to AWS
We built the frontend with React and TypeScript, using charts to make the water-usage information easier to understand.
The interface was only one part of the application. We also needed authentication, backend data models, and a way to send information beyond the dashboard.
We used AWS Amplify Gen 2 to define and connect the application's backend resources with the frontend. Working with backend definitions in TypeScript helped us keep the application and its cloud configuration connected through the development workflow.
Amazon Cognito provides user authentication and access control for the BuildingStaff group. This gave us a managed identity layer instead of requiring us to implement authentication from scratch.
Amplify Data defines the data models and API used by ReFlow. Our models represent three important concepts:
- Supply: information about available water supplies.
- AllocationPlan: planned water allocations.
- ActualUsage: recorded water consumption.
Keeping these concepts separate matters. Available supply, intended allocation, and actual usage are related, but they are not interchangeable.
This data model gives the application a foundation for connecting planning with recorded outcomes.
Part four: making the application useful beyond the dashboard
A dashboard is useful when someone opens it. But sometimes users need information without having to revisit the application.
We therefore implemented an email-reporting workflow using AWS Lambda and Amazon Simple Email Service (Amazon SES).
Lambda runs the reporting logic, while SES handles email delivery. The workflow is designed to send a daily water-saving tip and an illustrative usage summary to the recipient's inbox.
This adds a second way to access information from ReFlow: the dashboard supports exploration, while email brings a concise update directly to the user.
Testing the email-sending flow and receiving a test email helped us verify the basic delivery path. We also learned to distinguish that test from a fully verified scheduled production workflow. A successful manual invocation alone does not prove that a daily trigger is running reliably.
That distinction is important when building cloud applications. Every part of the workflow needs to be tested for what it actually does.
Part five: the engineering is in the connections
The challenge was not simply to put a chart on a webpage or send an email. It was to connect the pieces into a coherent application.
The planning interface needs to represent demand and available supply. The data layer needs to distinguish planned allocations from actual usage. Authentication must control access to the application. Reporting must use the intended information and deliver it through the email service.
Our AWS architecture assigns these responsibilities to different services:
- AWS Amplify Gen 2 connects the frontend and backend development workflow.
- Amazon Cognito handles authentication and group-based access control.
- Amplify Data defines the data models and API.
- AWS Lambda executes the email-reporting logic.
- Amazon SES delivers the reports.
This separation makes the system easier to reason about and gives us a starting point for future improvements.
It also showed us that cloud architecture is not just a diagram of service logos. Each service should have a clear responsibility in the product.
Part six: what we learned
Building ReFlow reinforced three lessons.
First, start with the decision users need to make.
The purpose of the dashboard is not to display as many numbers as possible. It is to help users understand available treated water, suitable demands, actual usage, and potential freshwater replacement. Every interface element should support that workflow.
Second, model the data according to what it represents.
A planned allocation and a recorded usage entry answer different questions. Keeping them distinct makes it easier to interpret the charts and reduces the risk of presenting a plan as if it were a real-world outcome.
Third, test the complete workflow, not just individual components.
A dashboard that renders correctly is not enough. Authentication, data access, record creation, chart calculations, and email delivery each need verification. A successful test of one component does not automatically prove the entire system works end to end.
We also learned to be precise about environmental claims. A prototype can demonstrate how water reuse might be planned without proving that a real building has reduced its freshwater consumption. That requires reliable measurements and real-world validation.
Part seven: what comes next
ReFlow is a starting point for making treated-water reuse easier to plan and understand.
The current prototype connects allocation planning, usage records, visual insights, authentication, backend data models, and an email-reporting workflow.
The next step is to validate the planning process with building operators and reliable usage data. Future development could explore integration with verified building measurements, better validation of water-quality suitability, and more detailed comparisons between planned and actual consumption.
Any real deployment would also need appropriate treatment and water-quality verification, operational review, and compliance with applicable standards. Software can support those decisions, but it cannot replace them.
Our goal is not to claim that a prototype has solved water scarcity. It is to explore how better planning and accessible information could support more responsible reuse.
Before we build further
ReFlow began with a practical question: if treated water is available, how can people plan to use it more effectively?
The project gave us a way to explore that question through a working interface and a cloud-connected architecture. It also gave us a clearer understanding of the work between an idea and a reliable application: data modelling, authentication, reporting, testing, and honest interpretation of results.
We built ReFlow to make water reuse easier to plan, track, and improve. The next challenge is to take that foundation beyond demonstration data and validate it against real building needs.
ReFlow — Give Every Drop a Second Chance.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article