A real-time overlay for a 50k-subscriber livestream
Broadcast graphics one operator drives live from a phone, that can never flash blank.
Real-time systems · broadcast · delivered, paid in full, Phase 2 commissioned
The problem
A creator runs a 24/7 plane-spotting livestream watched by tens of thousands of subscribers, mixed through a portable hardware encoder. They needed broadcast-quality on-screen graphics a single operator could drive live from a phone in the field: a tracked-flight lower third, a rotating movements board, alert stings, a cinematic go-around moment, super-chat callouts.
The graphics were never the hard part. The operating model was. The operator is on a phone in the field, but the overlay renders inside the encoder over the public internet, so the control surface and the display are on different devices in different places. And the overlay is on air, so it can never flash blank, not on a network blip, not on a refresh, not when the phone sleeps.
What I built
A complete, deployed system with two surfaces: an operator control panel behind a login, and a single public overlay page loaded into the encoder. It carries live flight data with a one-click live-or-sample toggle for rehearsal, flight locking with a live distance countdown, a filterable movements board, alert stings including auto-alerts for notable aircraft, the go-around moment with sound, super chats pulled from the live chat, and live airport weather.
The one decision that carried the reliability
The system is server-authoritative. The operator never talks to the overlay directly. It writes intent to a single source of truth, and the overlay renders whatever state it last saw, as a pure function of that state. That one design choice delivered the broadcast guarantees almost for free. On reconnect, the current state replays immediately, so a refreshed or dropped overlay re-renders the last good frame in under a second. It never flashes blank, and it stays consistent by construction.
I also wrapped the whole transport behind an interface identical in shape to the prototype’s, so I could move from a same-machine API to a networked relay across the internet without rewriting the render code. The data layer was pluggable too: I shipped on a free keyless flight feed, then later slotted in a paid feed and live weather behind the same boundary, without disturbing the rest of the app.
Professional delivery
Because the client is non-technical and might hand the code to another developer, documentation was a deliverable: an architecture document, a decision log, a requirements-traceability matrix mapping brief to code to verification, an operator guide, and hardware and data-provider guides. Security is by rules, not obscurity: the overlay is anonymous and read-only, and only the operator account can write. Every failure mode is mapped to a defined, no-blank behaviour.
Outcome
The MVP was delivered, deployed and accepted, with live flight data, cross-device control, login security and a full documentation set, some of it beyond the original brief. Paid in full, and the client commissioned a scoped Phase 2.