AWS Builder Center
I Built LoopZero Because One Complaint Doesn't Tell the Whole Story

I Built LoopZero Because One Complaint Doesn't Tell the Whole Story

What happens when the same drain stays clogged, the same garbage pile returns, or the same leak keeps getting ignored? I built a small prototype exploring how repeated environmental reports could become something more useful than a list of complaints.

I Built LoopZero Because One Complaint Doesn't Tell the Whole Story

I think one of the frustrating things about environmental problems is that you don't always need a big disaster to know something is wrong.
Sometimes it's the same garbage pile on the same road. The same open drain that nobody seems to fix. A water leak that keeps going. People notice these things, but each observation can end up feeling like a separate incident.
And that got me thinking: what if the problem isn't that nobody is reporting these issues, but that we're not connecting the reports?
That was the idea behind LoopZero, my project for Environmental Hacks.

The idea behind LoopZero

LoopZero is a small prototype for turning repeated environmental observations into what I call hotspots.
Instead of treating every report as an isolated complaint, the application groups observations based on their locality, issue category and landmark. It then builds a timeline and calculates a priority score based on persistence, recurrence and severity.
The basic idea is pretty simple. One report tells you that something happened. Several reports over time can tell you that something keeps happening.
I wanted to explore whether organising that information could make persistent environmental issues easier for residents and community groups to understand and communicate.

Okay, but what does it actually do?

I built a dashboard where you can explore environmental hotspots, filter them by issue type and status, and open individual cases to see their evidence timelines.
There is also a reporting form where users can enter a location, describe an issue, select its severity and optionally attach a photograph or location coordinates.
Each hotspot gets a score out of 100. The score combines three factors:
  • Persistence: How long the issue has been observed.
  • Recurrence: How many independent observations have been recorded.
  • Severity: The highest reported severity among the counted observations.
I also added CSV export and a printable evidence report, because I didn't want the information to exist only inside a dashboard.
One thing I was careful about was making the score explainable. A number on its own doesn't mean much if nobody understands where it came from. The score is a way to help organise priorities, not an official environmental or health-risk rating.

Building it under hackathon time pressure

For the first version, I used HTML, CSS and vanilla JavaScript.
I deliberately kept the application static instead of trying to build a complete backend in the limited time available. That let me focus on the main workflow: submitting an observation, grouping it with related reports, and showing why a hotspot deserves attention.
Of course, that shortcut comes with limitations.
Reports are currently stored in browser local storage. That means two different residents using different devices cannot automatically see each other's reports. Nothing is automatically sent to a municipal authority either.
The dashboard also contains fictional demonstration data so that someone opening the prototype can explore the features immediately. Those examples are labelled as demo data, because a working interface should not be confused with proof that a real-world impact has already happened.
These limitations are important. I would rather be clear about what the prototype can do today than pretend it is already a complete civic reporting platform.

The parts I still want to improve

If I continue developing LoopZero, the first thing I would work on is shared storage. The idea depends on multiple observations coming together, so eventually those observations need to be available across users and devices.
I would also improve how the application identifies related reports. People don't always describe the same place in the same way, and grouping unrelated issues together would be just as problematic as failing to connect reports that belong together.
A real pilot would be the next important step. I'd want to see whether residents actually find the reporting process useful, whether the grouping makes sense in practice, and whether evidence reports help people communicate recurring issues more effectively.
For now, LoopZero is an early prototype, not a proven solution. The impact is something that still needs to be tested.

A note on the tech and deployment

The current application is built with HTML, CSS and vanilla JavaScript and is hosted on GitHub Pages:
I wasn't able to complete AWS account setup and deploy the application on AWS during this build, so I have not claimed AWS service usage that didn't happen. I would still like to explore a proper cloud deployment and shared backend as the project develops.
I also used AI-assisted tools during prototyping. The important lesson for me was that getting a prototype on screen is only one part of building something useful. The underlying logic, the limitations, and how honestly you explain the result matter just as much.

What I took away from this

This project reminded me that a useful idea doesn't always have to begin with a complicated model or a huge technical stack. Sometimes it begins with noticing a recurring problem and asking whether the information around it could be organised better.
LoopZero still has a long way to go. It needs real observations, shared storage, community testing and a way to turn documented evidence into meaningful follow-up.
But the idea I wanted to explore remains the same:
One sighting is a signal. Repeated sightings are evidence.
And I'd like to see what we can build when we start treating them that way.


Build notes: LoopZero was developed using HTML, CSS and vanilla JavaScript, with browser local storage for the current prototype. AI-assisted tools were used during development. The application is a prototype and has not yet been validated through a real community pilot.
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article