The responding guard is the site's own security guard. The command room is that same security team's operators, plus the drone pilots - one room, both roles. Used daily, across multiple operational sites.

The drone gives a perspective nobody on the ground has, but a dropped feed isn't a failure state - it's a normal part of operating a drone in the field. The drone itself is built to continue its mission, or return to base if its battery runs low, and both the guard and the command room have other ways to keep working the incident without it.

Solo frontend, owning UX/UI and the implementation. I joined when the product was a single video stream and built it out from there - my first project, taken on as a junior with full ownership of the frontend.

The backend was a separate team: C#/.NET services, MongoDB for user management, and a Node.js API server running in Docker. I built against what they exposed.

"Same live picture" was the actual solution, not a description of the problem: the drone operator and the guard needed to see the same event, at the same time, so both could act on the same information. The command room also carries higher permissions than the guard - editing waypoints, gate positions, fences, and flight presets - so the same screen had to serve two different levels of control.

Sites with more than one drone add a second problem on top: a single command-room operator may need to watch and manage several drones at once, each with its own video feed and its own position on the map. The default single-drone view couldn't just stretch to cover that - it needed a dedicated view built for it.

As of when I left, it was in daily operational use across every deployed site - guards and command rooms working from the same live picture, real incidents included.

Move telemetry off polling and onto WebSockets. It was the plan the whole time I was there - it just never landed before I moved on. Polling works, but it's the wrong tool for something this real-time.