Live video streaming platform for surgical education

Overview

The platform lets surgeons broadcast live procedures to an online audience, with live chat, recordings, clips, and PDFs. A permissions system controls who can see and do what. Most visitors can watch and share published content. Chat, live streams, and joining the surgeon on Zoom for two-way discussion are reserved for verified medical professionals and students. Surgeons and coaches can also run streams for a closed group of their own students or mentees, a space only those users can enter.

I was brought on as the developer on the day the founder started the project. We built it on top of an open-source streaming project, which gave us a starting point: live-streaming, saved recordings, chat, and clips. It was made as a community project, not for a commercial product handling medical content, so much of it had to change. The upstream project was abandoned a few months in, so from then on the whole codebase was ours to maintain, with no updates coming from anywhere else. All development was mine. I helped get the project running on AWS and later took over the infrastructure entirely.

What I built

• Live-streaming through Zoom. A surgeon creates a stream from the dashboard, Zoom opens with the meeting already set up, and they’re live on the platform in two or three clicks. Nothing to install or configure on their end. I built the Zoom integration and reworked the inherited NGINX-RTMP server to take encrypted RTMPS streams from Zoom, which the platform needed for HIPAA compliance.
• Clips as the main content. The original project published every recording. Here, a live stream is saved as a recording that only the streamer can see. They cut clips from it and publish just those. I reshaped the content model and the site around clips as the thing people watch.
• Making it reliable. The inherited code had a few weak spots that caused errors in unrelated places and were hard to trace. Chat ran on an old Ejabberd release with shaky communication to the app. FFmpeg was driven through raw shell commands with little error handling. And the services only talked to each other through file naming conventions, each rebuilding paths on its own. I upgraded Ejabberd and streamlined how the app talks to it, moved FFmpeg behind a Python wrapper with proper error handling, made the database the source of truth for media paths, and replaced a startup script that patched data on every launch with real migrations.
• Move to managed AWS. The first production setup was a single unmanaged VPS. I moved the three services, the Flask app, the video server, and the chat server, into Docker containers on ECS Fargate, with RDS for the database, EFS for media, and automated deployments through CodePipeline.
• Paid memberships. Free users get a limited set of content. Selected users can upgrade through Stripe, which unlocks more clips and live streams. I built the subscription flow and the webhook handling behind it.
• PDFs alongside videos. Users can upload PDFs, which appear in the same feeds as clips and videos. Thumbnails are generated from them automatically, so they look consistent with everything else.

Key decisions

Stream through Zoom, not a dedicated encoder. The surgeons doing the broadcasting already used Zoom every day. Pointing them at OBS or a browser encoder would have been simpler on our side, but every new streamer would have needed setup help. So the platform drives Zoom instead: it creates the meeting with the right details, and the stream lands on the site, and The surgeon only does what they already do every day. The cost was more work on our end, including RTMPS support in the video server.

Start from the open-source project rather than from scratch. We weighed building the platform from nothing. I recommended starting from the open-source project because it already had live-streaming, recordings, chat, and clips working end to end, which meant a usable product in weeks rather than months. The trade was inheriting code never meant for commercial use and reworking it piece by piece, which became entirely our job once the upstream project was abandoned.

Self-hosted video instead of a hosted video API. Hosted video services came up early. They would have saved setup time, but per-minute pricing adds up fast with long surgical streams, and sending medical footage through a third party raised compliance questions. We kept the video pipeline in-house and agreed to revisit it only when the platform outgrew what the setup could handle.

Managed services over a hand-run server. The first setup was a single server we maintained ourselves. Moving to managed AWS services meant the backend stayed up without someone watching it, scaled on its own, and met the security requirements that come with medical content. It costs more than a bare server, but for a platform run by one engineer, and the time I would have spent on servers went into the product.

Load only what the user is looking at. The inherited management page loaded everything a user owned at once, every channel, video, clip, and setting, with heavy front-end code on top. I broke it into small sections: a paginated list of channels, then a chosen channel’s videos, clips, or settings, each loaded only when opened. Pages got lighter and faster, and the structure stayed easy to extend.

How it went

The platform is live and in use. For years, I was its only engineer, working directly with the founder and owning the architecture, the AWS setup, deployments, and every feature from the Zoom integration to memberships. I wrapped up my work once the product was stable and the focus moved from new development to growing the user base.

What I’m most pleased with is how reliably it ended up running. Early on the site struggled with errors that appeared at random and were hard to trace back to a cause. Getting it to the point where everything just worked took a long time. It ran alongside feature work for a long stretch, piece by piece. But it got there: a platform that no longer needed close watching, where live surgeries went out without anyone worrying about what was running underneath.