We Treated Potholes Like Software Bugs and Accidentally Built a Civic Hacking Playbook

The Problem: Potholes as Unseen Failure Points

Every commuter in a midsized city knows the feeling – a sudden jolt, a tire‑rim kiss, and the inevitable slowdown while a crew patches the road. Potholes are more than a nuisance; they represent a feedback loop that city engineers struggle to close. Traditional processes rely on citizen calls, manual inspections, and a schedule that can lag weeks or months. By the time a repair is logged, the hole often deepens, causing vehicle damage, traffic delays, and higher maintenance costs.

The Experiment: Treating the Road Like Code

A small collective of civic‑tech hobbyists, led by Bogomil Petrov, decided to apply a software‑development mindset to the problem. Instead of digging into the asphalt, they focused on the visibility layer – the data that tells a city whether a defect exists. Their hypothesis was simple: if you can observe a defect as quickly and reliably as a failing unit test, you can trigger an automated remediation workflow.

Building the Sensor Stack

1. Low‑cost vibration sensors – salvaged from discarded smartphones and mounted on street‑light poles. These devices stream 10 Hz accelerometer data to a local edge gateway.
2. Edge inference – a TensorFlow‑Lite model runs on a Raspberry Pi 5, classifying vibration signatures as "normal traffic" or "anomalous impact". The model was trained on a dataset of 12 k labeled events collected during a pilot in the downtown district.
3. Message bus – detected anomalies are published to an MQTT topic hosted on a public‑cloud broker (AWS IoT Core). Each message contains GPS coordinates, timestamp, and a confidence score.
4. Dashboard & alerting – a React‑based UI aggregates the stream, visualizing hot spots on a Mapbox map. When a cluster of high‑confidence events exceeds a threshold, a webhook fires to the city’s work‑order system.

The “CI/CD” Pipeline for Streets

The team borrowed terminology from continuous integration:

• Commit – a sensor reports an anomaly, analogous to a code change that breaks a test.
• Build – the edge model aggregates multiple reports, forming a "build artifact" (a pothole candidate).
• Test – a secondary validation step cross‑references the candidate with recent weather data and traffic volume to reduce false positives.
• Deploy – an automated ticket is created in the municipal asset‑management platform, assigning a crew and estimating material needs.

Because the pipeline is fully observable, city officials can watch the deployment in real time, similar to watching a CI job log.

Results: Faster Detection, Smarter Allocation

During a six‑week pilot covering 3 km of arterial road, the system logged 1 842 anomaly events. After the test‑validation stage, 127 unique pothole locations were confirmed. Compared with the city’s historical average of 42 reported holes in the same stretch, the detection rate increased by 300 %.

More importantly, the average time from detection to crew dispatch dropped from 12 days to 2 days. The city reported a 15 % reduction in vehicle‑damage claims for the pilot area, translating to roughly $250 k in avoided costs.

The Playbook: What Other Cities Can Reuse

1. Start Small, Scale Fast – Deploy a handful of sensors on existing infrastructure (lampposts, traffic signals). The hardware cost per node is under $45.
2. Open‑Source First – The team released their firmware, model, and dashboard under the MIT license on GitHub (sensor‑firmware). This lowers the barrier for municipalities to audit and adapt the code.
3. Integrate, Don’t Replace – Rather than building a brand‑new work‑order system, the pipeline pushes events to the city’s existing GIS‑based asset manager via a simple REST endpoint.
4. Iterate on the Model – Collecting more labeled data improves detection precision. The team set up a crowdsourced labeling portal where residents can confirm or reject a reported hole, feeding back into model retraining.
5. Measure Impact – Track both operational metrics (time‑to‑repair) and downstream effects (vehicle‑damage claims, traffic slowdown). Transparent reporting builds trust with stakeholders.

Limitations and Trade‑offs

• Sensor Coverage – The approach depends on a dense enough sensor network; sparsely instrumented suburbs may need alternative detection methods (e.g., computer‑vision from dashcams).
• False Positives – Heavy trucks or construction activity can generate vibration signatures that mimic potholes. The validation stage mitigates this but adds latency.
• Data Privacy – Streaming location‑tagged sensor data raises concerns. The team anonymized raw accelerometer streams and only retained aggregated hotspot data.

Looking Ahead: From Potholes to a Full‑Scale Civic CI Platform

The experiment proved that treating urban defects as software bugs is more than a metaphor. By exposing the "visibility layer" through cheap sensors and open‑source tooling, cities can create a feedback loop that continuously surfaces and resolves issues. The next logical step is to extend the pipeline to other infrastructure elements—street‑light outages, water‑leak detection, and even graffiti monitoring.

If municipalities can adopt this playbook, the cumulative effect could be a city that self‑diagnoses, self‑prioritizes, and self‑heals much like a modern software system. The key is keeping the stack simple, transparent, and community‑driven.

{{IMAGE:2}}

For a deeper dive into the sensor firmware and the machine‑learning model, see the project's GitHub repository and the accompanying technical blog post linked in the article.