A Better Neighbourhood

Hero
Report Tracing
Reports
Reporting an Issue

Inspiration

Every street we walk down has the same problems: potholes that get worse every monsoon, streetlights that stay dead for weeks, and bins that overflow. Everyone complains about them, but almost nobody reports them. When someone does, the complaint goes into a phone line or a form and they never hear back, so people stop trying.

The system fails on both sides. Residents have no reason to report, because nothing visibly happens. The municipality gets a flood of vague, repeated and sometimes fake complaints, with no clear signal of what matters most. Ten calls about one pothole look like ten problems.

There's also a harder problem underneath. When roads stay broken for months, people assume the money went somewhere it shouldn't have, and right now there is no way to check. Nobody outside the corporation can see how many complaints came in, how long each one took, or whether "fixed" actually means fixed.

We wanted to fix all three: make reporting fast and visible for residents, give officials a clean queue they can trust, and give higher authorities a public record they can hold the corporation accountable to.

What it does

A Better Neighbourhood (ABN) turns every resident's phone into a verified sensor for civic problems. It gives the municipal corporation one prioritised queue of real, located, de-duplicated issues, and it keeps a public, timestamped ledger of how every issue was handled.

For residents

Open the in-app camera and take a live photo. The report is pinned to your exact GPS location and appears on a public noticeboard in under a minute.
Upvote issues your neighbours have already raised. Milestones at 10, 50 and 100 upvotes are added to the issue's timeline.
Comment with text and up to 4 photos to add evidence.
Track every report through Reported → In progress → Fixed, along with each official update.
Browse, search and filter what's happening nearby. Browsing doesn't need an account.

For the municipal corporation

A dashboard with totals by status and the latest reports.
A priority list that ranks open issues by upvotes, so the problems affecting the most people come first.
Each report includes the live photo, a map pin, a reverse-geocoded address and every merged repeat report, so crews go to the right spot.
Official comments appear publicly, marked as coming from the local authority.
Filtering and CSV export for ward reviews and budget planning.

For oversight: an accountability ledger

Every action on a report is logged with a timestamp: when it was filed, every upvote and merged duplicate, every status change and official comment, and when it was resolved. Nothing is silently edited or deleted. This turns ABN from a complaint box into a public ledger of how the corporation responds.

On top of this ledger, ABN gives higher authorities, such as the state urban development department or the district administration, a view of how each corporation and ward is performing:

Average time from report to resolution
Open backlog and how long issues have been waiting
Resolution rate by issue type and by ward
Heavily upvoted or frequently re-reported issues that are still open
Issues reopened after being marked fixed

This gives authorities a fair, data-backed basis for performance reviews and funding decisions, instead of relying on the corporation's own reporting. It also gives honest officials a record of the work they've actually done.

Built for trust

Because these reports feed a performance record, they have to be hard to game from either side. Four safeguards make sure every report is real, located and unique:

Live photo, live location. You can't upload from your gallery, and the shutter stays locked until the phone has a GPS fix.
One account per phone number. This makes throwaway spam accounts costly.
AI verification. A YOLOv8 model checks every photo before the report is saved. Reports without a valid issue are rejected, and the model assigns the category so labels stay consistent.
Automatic duplicate merging. If an open report of the same type already exists within 5 metres, the new one is merged into it, and its photo and upvote are added to the original. Ten residents reporting one pothole produce one job with ten voices behind it.

The append-only timeline works the same way from the other side: no one can make a backlog disappear on paper.

How we built it

ABN is four repos: two front ends that talk to one API, which is the only part allowed to touch the database, the photo store and the detection model.

Resident web app built with Next.js 16 (App Router), React 19, TypeScript, Tailwind CSS and shadcn/ui, with TanStack Query for data fetching and react-hook-form with Zod for validation. It uses react-webcam with the back camera and the browser's Geolocation API to enforce live capture and to block the shutter until there's a GPS lock. There is no file upload path at all.
Backend API built with Node.js, Express 5 and TypeScript, using Prisma 7 on PostgreSQL with the PostGIS extension. It handles accounts (bcrypt-hashed passwords, a JWT in an httpOnly cookie), reports, upvotes, comments and the append-only activity log behind every report's timeline. Duplicate detection is a single PostGIS ST_DWithin query that finds open reports of the same type within 5 metres, and merges run in one database transaction. Photos go to S3-compatible object storage.
Detection model. YOLOv8n, trained for 100 epochs at 416×416 on a custom Roboflow dataset plus public Kaggle pothole and Indian road datasets, with clean roads and faces as negative examples. It's served with FastAPI in Docker on Hugging Face Spaces. Every submitted photo goes through it for verification and labelling before it's saved. On our validation set it reaches precision 0.75, recall 0.63 and [email protected] of 0.70.
Admin panel built with Next.js 16, React 19 and Redux Toolkit, with the dashboard, priority list, report details, official comments and CSV export.

Reverse geocoding through OpenStreetMap's Nominatim turns coordinates into readable addresses for field crews, shown on an OpenStreetMap pin.

Challenges we ran into

Forcing a truly live report in a web app. Browsers make it easy to pick a file from the gallery. Locking capture to the live camera and holding the shutter until a GPS fix arrived took far more work than we expected across different phones and browsers.
Picking the duplicate radius. Phone GPS drifts by several metres. A radius that's too small lets duplicates through, and one that's too large merges two separate potholes on the same street. We settled on 5 metres within the same issue type.
Training on limited data. Pothole images vary a lot with lighting, rain and camera angle. Recall of 0.63 means the model still misses some real potholes, so we had to balance rejecting fake reports against frustrating genuine ones.
Keeping inference fast on free hosting, so verification doesn't slow down reporting.
Designing accountability that's fair. A performance record is only useful if both sides trust it. We had to think about how residents might inflate problems and how records might be quietly altered, and design against both.

Accomplishments that we're proud of

The full resident flow works end to end for potholes: live capture, AI verification, duplicate merging and the public timeline.
We trained our own YOLOv8 model and deployed it to check real submissions, not a mocked API call.
The trust design. Live-only capture, one account per number, AI checks and automatic merging mean the city receives signal, not noise.
Every report is a public ticket with a full, timestamped history, so residents, officials and higher authorities all look at the same record.

What we learned

Civic tech is mostly a trust problem. The features that mattered most weren't the flashy ones. They were the ones that stopped fake, vague and duplicate reports.
Visibility drives participation. People keep reporting when they can see their report move.
Accountability works best when it isn't adversarial. A shared, timestamped record protects good officials as much as it exposes slow ones, and that framing matters if municipalities are going to adopt it.
Training a model is the easy part compared with collecting good data and choosing a threshold that's fair to real users.
Privacy needs attention from day one. Reviewing our own API, we found the public report endpoint was returning reporter contact details, and we put fixing that at the top of our list.

What's next for A Better Neighbourhood

Privacy hardening. Stop public endpoints from exposing reporter contact details.
OTP phone verification, so one account really means one person.
More issue types: garbage, broken streetlights, water leaks and noise sources, alongside potholes.
Complete the official workflow. Connect the admin panel's status changes to the API, and require a proof-of-fix photo when an issue is closed.
Oversight dashboard for higher authorities, with read-only access to resolution times, backlog and ward-by-ward performance comparisons.
Tamper-evident ledger. Hash-chain each timeline entry so the record can't be altered after the fact.
City-wide map and heatmap, so officials can see clusters by ward.
Role-based accounts for municipal officials and oversight authorities.