I built the NYC surveillance app first as a fast, map-based way to monitor live traffic cameras and understand street conditions in real time. The initial focus was simple: make camera discovery fast, keep the interface clear, and reduce the friction between opening the app and seeing what was happening on the street. Because the NYC version had access to MTA data, the project evolved beyond camera viewing into a broader commuting tool. That is where the commute analyzer came in. By integrating the MTA API, I was able to add a layer that helped interpret whether delays on a route were likely to affect a user’s trip, which made the app feel less like a camera dashboard and more like a practical urban mobility tool.

Building the Georgia version was a different kind of engineering problem. Instead of starting from scratch, I used the NYC app as the base and adapted the architecture to work with 511ga. That meant reworking the camera ingestion pipeline, changing map defaults and search behavior, and handling a different video delivery model. The Georgia feeds required more effort because the public camera API did not expose direct stream URLs the way the NYC app’s flow effectively allowed. I had to resolve tokenized live stream URLs dynamically, support HLS playback, and add token refresh logic so feeds would not die after a short period. That made the Georgia app a good example of platform adaptation: same product goal, but different infrastructure constraints and a different technical solution.

What tied both projects together was the product thinking behind them. The NYC app showed how public transit and street-camera data could be combined into a more useful commuting experience, especially through the commute analyzer powered by MTA data. The Georgia app showed how to take that same core concept and rebuild it around a different public data ecosystem without losing usability.