Building BlueLoop on AWS: Turning Industrial Water Reuse into a Deployable Platform
How we built and deployed BlueLoop, a water reuse procurement prototype, using AWS serverless services-and what we learned about authentication, deployment reliability and the gap between a working demo and production readiness.
The problem we wanted to solve
Water reuse is not just an environmental issue. For industrial facilities, it is also a coordination and procurement challenge.
One facility may generate treated wastewater that could be suitable for reuse, while another may need water for an industrial application such as cooling. Connecting these two sides is not as simple as comparing available volume and price. The intended use, water quality, compliance requirements, transport constraints and delivery verification all matter.
We started building BlueLoop around this problem: how might we make industrial water reuse easier to discover, evaluate, coordinate and track?
Our goal was to bring the major steps of a potential reuse transaction into one workflow instead of treating supplier discovery, buyer requirements, quality evaluation and delivery tracking as separate activities.
What BlueLoop does
BlueLoop is an industrial water reuse intelligence and procurement platform designed for treated-water suppliers, industrial buyers and platform administrators.
The prototype brings together six major capabilities:
- Supplier discovery: Explore available treated-water streams, indicative volumes, pricing, water grades and laboratory evidence.
- Demand management: Represent buyer requirements, intended use, volume, budget and acceptable quality boundaries.
- Quality-aware matching: Evaluate candidate supplies against buyer requirements and expose eligibility or rejection reasons.
- Allocation proposals: Organize feasible matches into a procurement workflow.
- Delivery tracking: Follow a transaction through scheduling, dispatch, transit, sampling and confirmation.
- Impact reporting: Distinguish potential impact from accepted and confirmed outcomes instead of treating every proposal as a completed environmental benefit.
The idea is to help users reason about the full transaction, not just find a supplier.
You can explore the project here:
- Live demo: https://d3h3pxn0bzvtvq.cloudfront.net
- Source code: https://github.com/nextgendev2029/BlueLoop
The current application uses synthetic demonstration data. It is a prototype, not yet a validated marketplace with real industrial customers or independently measured environmental outcomes.
Why we chose a serverless AWS architecture
We wanted to make BlueLoop accessible through a live URL without managing a traditional application server.
The frontend uses React, TypeScript and Vite. The backend uses Python and FastAPI, with Mangum connecting the API application to AWS Lambda.
Our deployed architecture uses the following AWS services:
Amazon S3 and Amazon CloudFront
We build the frontend into static assets, store them in a private S3 bucket and deliver them through CloudFront over HTTPS. Origin Access Control keeps direct public access to the bucket restricted while allowing CloudFront to retrieve the website assets.
Amazon API Gateway and AWS Lambda
API Gateway exposes the HTTPS API endpoints, while Lambda runs the Python backend. This separation allows the frontend and backend to be deployed independently.
AWS SAM and AWS CloudFormation
We define the infrastructure through an AWS SAM template and use the SAM CLI to validate and deploy it through CloudFormation. This makes the deployment process more reproducible than manually recreating each resource.
Amazon CloudWatch
CloudWatch provides backend logs that are useful when investigating runtime errors and understanding what happens after deployment.
Together, these services took BlueLoop from a local development project to an application accessible over HTTPS.
The lesson that changed our implementation
One of the most useful lessons came after the initial deployment.
A successful infrastructure deployment does not automatically mean that the application is reliable.
Our first version used SQLite session data stored under Lambda's temporary filesystem. That approach introduced a problem: different Lambda execution environments do not share the same local filesystem. A session that appeared to work in one environment could behave inconsistently when another environment handled a request.
The symptom was especially frustrating because the dashboard could load while individual protected API requests failed authentication.
We investigated the authentication flow and changed the session design to use stateless HMAC-SHA256-signed tokens. We also tested the deployed authentication flow and addressed issues in the allocation workflow.
This taught us to verify the complete user journey—not just the health endpoint or the CloudFormation stack status.
For a web application, the real test is whether users can sign in, refresh a protected page, make authenticated API requests and complete the intended workflow consistently.
What still needs to improve
The current deployment is a hackathon prototype, and there are important limitations we do not want to hide.
The backend uses SQLite in Lambda's temporary storage, and the application uses synthetic demonstration data. Temporary storage is not durable shared storage, and local records cannot be assumed to persist across Lambda environment replacement or remain synchronized between concurrent instances.
A production-ready version would need a persistent shared database, stronger operational controls, careful authorization and data governance, and validation with actual suppliers and industrial buyers.
We would also need to test the quality evaluation and impact-accounting logic against real operational requirements before presenting its results as evidence of compliance or environmental savings.
Where the business opportunity could be
We see BlueLoop as a possible B2B platform for industrial facilities, water-treatment operators and procurement teams.
Potential business models include enterprise subscriptions, procurement or transaction fees, and reporting and analytics services. However, these are hypotheses to validate, not an established revenue model.
The next step would be conversations with real stakeholders: understanding how they currently source or dispose of treated water, what prevents reuse transactions from happening, which quality and regulatory requirements are essential, and who would pay for better coordination.
Technology can make a workflow easier to manage, but the business must prove that it solves a sufficiently important problem for the people who would use it.
Final thoughts
Building BlueLoop taught us that cloud development involves much more than getting code to run in the cloud.
It means making architectural choices, understanding the lifecycle of application state, investigating failures across service boundaries and being honest about what has—and has not—been verified.
AWS gave us a practical way to deploy the prototype using managed services and a repeatable infrastructure workflow. Just as importantly, the deployment exposed problems that local development alone had not made obvious.
BlueLoop is an early step toward making industrial water reuse more coordinated and traceable. Our next challenge is to move beyond synthetic demonstrations, validate the workflow with real stakeholders and build the persistent infrastructure required for a reliable multi-user product.
The broader lesson is simple: a successful deployment is a milestone, not the finish line.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article