WATERLOOP: Water Reuse with AWS Lambda
WATERLOOP is a water-reuse planning prototype built by Team EarthOps for AWS Environmental Hacks 2026. Using AWS Lambda, it allocates treated water across non-potable uses based on priorities and availability. The dashboard visualizes allocation, remaining supply, and estimated freshwater savings, with preliminary water-quality checks. WATERLOOP explores smarter water planning to help make every litre count.
Building WATERLOOP: My Journey Exploring Smarter Water Reuse with AWS Lambda
1. The Beginning: Turning an Environmental Problem into a Project
Participating in WeMakeDevs AWS Environmental Hacks 2026 gave me an opportunity to explore how technology could help address a real-world environmental challenge.
Our team, EarthOps, chose to focus on water scarcity and the need to use available water resources more intelligently.
Cities face growing water demand, and not every application requires drinking-quality water. With appropriate treatment and verification, reclaimed water can serve certain non-potable purposes, such as toilet flushing, landscaping, and vehicle exterior washing.
However, having water available is only part of the challenge. When supply becomes limited, deciding how to distribute it across competing uses becomes equally important.
That question inspired WATERLOOP — Smart Water Reuse & Allocation, a prototype designed to demonstrate how treated water can be allocated according to availability and the priorities assigned to different uses.
My goal was to turn this idea into a working application while learning more about frontend development, backend logic, and AWS cloud services along the way.
2. Introducing WATERLOOP
WATERLOOP is a water-reuse planning prototype that demonstrates how allocation decisions can adapt to changing water availability.
The application focuses on three non-potable uses:
- Toilet flushing
- Landscaping
- Vehicle exterior washing
Users can explore different supply scenarios and observe how the allocation plan changes.
Rather than presenting only numerical results, the dashboard makes the allocation process easier to understand by displaying available water, allocated quantities, remaining supply, and illustrative estimates of potential gross freshwater-displacement savings.
The project also includes preliminary turbidity and pH checks for the toilet-flushing use case, highlighting an important principle: water allocation decisions must consider suitability for the intended application, not just the quantity available.
WATERLOOP is an early prototype rather than a complete water-management system, but it provides a practical starting point for exploring smarter water-reuse planning.
3. Exploring the Allocation Logic
One of the central parts of WATERLOOP is its ability to respond to different supply conditions.
To demonstrate this, I tested two illustrative scenarios.
Scenario 1: Normal Water Supply
Imagine that 500,000 litres of treated water are available per day.
In this scenario, WATERLOOP allocates:
Application | Daily allocation |
|---|---|
Toilet flushing | 80,000 litres |
Landscaping | 100,000 litres |
Vehicle exterior washing | 70,000 litres |
Total allocated | 250,000 litres |
Remaining supply | 250,000 litres |
The dashboard also displays an estimated gross savings figure of ₹12,500 per day, based on the prototype's assumed freshwater-displacement value.
These figures are illustrative estimates, not measurements of actual savings.
Scenario 2: Water Shortage
Next, I reduced the available supply to 150,000 litres per day.
WATERLOOP recalculates the distribution:
Application | Daily allocation |
|---|---|
Toilet flushing | 80,000 litres |
Landscaping | 70,000 litres |
Vehicle exterior washing | 0 litres |
Total allocated | 150,000 litres |
Remaining supply | 0 litres |
The comparison demonstrates how the allocation plan can change when the available supply decreases, preserving allocations for higher-priority uses while reducing lower-priority allocations.
This was an important part of the project because it made the environmental problem tangible. Instead of discussing water scarcity only in theory, I could demonstrate how a planning tool responds to changing conditions.
The financial figures are indicative gross estimates. Actual savings would depend on factors such as treatment, pumping, conveyance, and operating costs, as well as how much freshwater is genuinely displaced.
4. Building the Application
WATERLOOP combines a frontend dashboard with Python-based allocation logic running on AWS Lambda.
The main components are:
Frontend Dashboard
The frontend provides the interface for exploring supply scenarios and viewing allocation results.
Its purpose is to make the planning process understandable without requiring users to inspect the underlying calculations.
Python Allocation Logic
The allocation logic processes scenario inputs and calculates the distribution according to available supply and assigned priorities.
Keeping this logic separate from the presentation layer makes the responsibilities of the frontend and backend easier to understand.
Connecting the Components
The frontend sends scenario inputs to the backend and displays the returned allocation plan.
This interaction connects the user-facing interface with the underlying calculations, allowing the dashboard to respond to different scenarios.
Developing this workflow also gave me practical experience with the relationship between frontend applications, backend processing, and HTTP communication.
5. Using AWS Lambda
One of the key technical aspects of WATERLOOP was integrating AWS Lambda into the application.
AWS Lambda runs the Python-based allocation logic without requiring me to manage a dedicated application server for the prototype.
I configured a Lambda function and used a Lambda Function URL to provide an HTTP endpoint through which the frontend could send scenario inputs and receive allocation results.
The basic workflow is:
- The user explores a water-supply scenario in the frontend.
- The frontend sends the scenario inputs to the Lambda Function URL.
- AWS Lambda executes the allocation logic.
- The function returns the calculated allocation plan.
- The frontend displays the results.
This architecture allowed me to explore how serverless computing can support a small application that performs useful calculations in response to user input.
It also helped me understand that using a cloud service involves more than writing the function itself. The application must communicate with the endpoint correctly, and its configuration must support that interaction.
For this project, AWS Lambda was the principal AWS service used. The prototype's preliminary water-quality checks remain in the frontend and are not independently enforced by the Lambda function.
6. Considering Water Quality
An allocation plan is useful only when the water is suitable for its intended purpose.
That is why WATERLOOP includes preliminary checks for turbidity and pH for the toilet-flushing use case.
When the configured checks fail, the prototype indicates that the water is not compatible and holds the allocations in its interface.
This demonstrates how water-quality considerations can be incorporated into a planning workflow rather than treating water solely as a numerical resource.
However, these checks are limited. They do not establish that water is safe for use, replace comprehensive laboratory testing, or certify compliance with applicable standards.
A real-world implementation would require appropriate treatment, comprehensive water-quality verification, and compliance with the relevant regulations and standards.
For me, this was an important design consideration: a useful prototype should make its limitations clear instead of presenting preliminary checks as proof of safety.
7. Challenges and What I Learned
Building WATERLOOP gave me an opportunity to explore both the application logic and the practical details involved in connecting a frontend to a cloud service.
One challenge was understanding Cross-Origin Resource Sharing, commonly known as CORS.
Browsers apply origin restrictions when a frontend makes requests to a different origin. An origin includes the protocol, hostname, and port. Consequently, a frontend running on a different development port may require a matching CORS configuration on the backend.
Working through this issue helped me understand why an application can work locally in one configuration yet encounter browser errors when its origin changes.
I also learned the importance of testing different scenarios instead of relying on a single successful example. Testing both normal supply and shortage conditions helped me check whether the allocation logic responded as expected.
The experience reinforced several lessons:
- The idea is only the starting point. A useful project requires translating the problem into specific inputs, rules, and outputs.
- Integration matters. A frontend and backend must communicate correctly for the complete application to work.
- Testing different scenarios matters. Normal conditions alone do not reveal how a system responds to constraints.
- Cloud configuration is part of development. Runtime settings, HTTP endpoints, permissions, and CORS can all affect application behaviour.
- Limitations should be explicit. A prototype should not claim to provide guarantees that its implementation cannot support.
These lessons are valuable beyond WATERLOOP. They apply to many applications that combine user interfaces, backend logic, and cloud services.
8. What Could Be Improved Next?
WATERLOOP is a prototype, and there are several directions in which it could develop further.
More Realistic Allocation Strategies
Future versions could incorporate more detailed demand estimates, configurable priorities, and additional allocation constraints to better represent real facilities.
Better Water-Quality Integration
The prototype could be extended to consume verified water-quality data and apply requirements appropriate to each intended use. Any such system would need suitable validation and regulatory review.
More Complete Cost Estimation
The current savings figures are illustrative gross estimates. A more comprehensive model could account for treatment, pumping, conveyance, maintenance, and other operating costs to estimate potential net benefits.
Integration with Real Data
Future development could explore how measured supply, demand, and water-quality information might inform allocation decisions.
These are possible future directions rather than features already implemented in WATERLOOP.
9. What This Experience Meant to Me
This hackathon was an opportunity to take an environmental problem and turn it into a working technical prototype.
Through WATERLOOP, I explored Python-based allocation logic, frontend-backend communication, AWS Lambda, and the practical considerations involved in integrating a cloud service into an application.
I also gained a better appreciation for the difference between demonstrating an idea and building a system ready for real-world use. A prototype can make a concept easier to understand, but reliability, validation, security, and real-world data require further work.
The experience reminded me that learning software development is not only about understanding individual technologies. It is also about connecting them, testing their behaviour, investigating problems, and making thoughtful decisions about what a system can and cannot do.
10. Conclusion: Making Every Litre Count
Water scarcity is a complex problem that cannot be solved by software alone. It requires appropriate infrastructure, effective water management, suitable treatment, and informed decisions.
However, technology can help people explore those decisions more clearly.
WATERLOOP demonstrates one small way to approach the challenge: make available supply visible, compare allocation scenarios, and show how a plan can respond when water becomes limited.
Building this prototype gave me practical experience with AWS Lambda while allowing me to explore an environmental problem that matters.
There is still much that could be improved, but the project represents a meaningful starting point for further learning and development.
The goal is not simply to find more water. It is to make smarter, more informed use of the water already available.
WATERLOOP — Make Every Litre Count.
Project links
- GitHub repository: https://github.com/kkrupaprafulla-code/WaterLoop
- Demo video: https://youtu.be/HeP-x-BOwWQ
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article