UGA Parking Watch
Problem and Motivation
UGA's parking enforcement is relentless. I once walked out of a building to find a ticket on my car after being parked for less than ten minutes. I knew I wasn't alone, and nearly every student on campus has a version of that story. The problem isn't that tickets are undeserved, it's that students have no visibility into where enforcement is actively happening at any given moment.
Waze solved the same information asymmetry for drivers and speed traps. The fix felt obvious: give students a way to crowdsource parking attendant sightings in real time so the entire campus benefits from what any one person already knows. That was the idea behind UGA Parking Watch, and designing the system to do that well turned out to be a more interesting problem than I initially expected.
Approach and System Design
The app is built on Next.js with Firebase handling authentication and the live data layer. Students sign in with Google, tap a lot on the map or hit "Add report," select the enforcement type (patrol, ticketing, boot, or gate closure), and submit. That report becomes immediately visible to everyone else on the map via a real-time Firestore listener scoped to the last 24 hours.
To add a layer of trust to crowdsourced data, the system includes a confirmation mechanism: other users can confirm an existing report, incrementing its score, but you cannot confirm your own report and cannot confirm the same report twice (enforced via a Firestore transaction). The idea is that score reflects genuine independent sightings rather than a single user's word. Lot data is loaded from a local GeoJSON file of UGA parking lots with centroids computed at runtime, and the add-report flow uses device geolocation with accuracy thresholds and teleport rejection to pre-select the nearest lot intelligently rather than blindly snapping to the closest coordinate.
The most ambitious piece of the design was a planned integration of historical ticket data obtained through a Georgia open records request. The vision was to layer crowdsourced real-time sightings on top of historical enforcement patterns by lot, time of day, and day of week, so the map could show not just where an attendant was spotted five minutes ago but where enforcement statistically tends to concentrate. That combination of live signal and historical baseline is what would have made the tool genuinely predictive rather than purely reactive.
Challenges and Tradeoffs
The hardest design problem was report reliability. A 24-hour window is a blunt instrument: a report from 23 hours ago sits in the same feed as one from 5 minutes ago, and the confirmation system's effectiveness is limited when user density in a given area is low. The right solution is time-decay scoring so that recent reports carry meaningfully more weight than old ones, and the map reflects that difference visually. Without it, a sparse feed and a stale feed look identical to the user.
The cold-start problem is the deeper issue underneath that. A crowdsourced tool is only as useful as its active user base, and at low adoption the map is too sparse to rely on. The historical ticket data layer was partly designed to address this: even with zero live reports, the map could still surface statistically high-risk lots based on past enforcement records, giving the tool value from day one rather than only after it reached critical mass.
Outcomes and Impact
Designed and partially built a real-time crowdsourced enforcement map with Google authentication, live Firestore sync, and a transaction-backed confirmation system.
Identified a novel data layer (historical ticket records via open records request) that would have made the tool predictive rather than purely reactive, and designed the system architecture around eventually incorporating it.
Limitations and Next Steps
This project was ultimately shelved. The further I got into it, the more I thought carefully about what it meant to build a tool explicitly designed to help students evade enforcement at my own university, and I was not comfortable with the risk that it could create problems for me there. That was the right call, and I made it deliberately.
What the project left me with is a clear picture of what the complete version would have looked like: time-decay scoring on live reports, a confidence tier system that displays unconfirmed reports differently from corroborated ones, push notifications for saved or nearby lots, and a historical enforcement heatmap built from open records data that gives the map baseline value even before crowdsourced activity fills in. The design thinking was sound. Finishing it was a different question.