Building a WebRTC Video Conferencing Platform From Scratch

As tech lead at Kintry, I built Zoom-like video conferencing from scratch using WebRTC and Socket.io, as part of a platform that also shipped five Android and iOS apps to 50,000+ downloads and a microservices backend handling live streaming, chat, and payments. Reaching for a hosted SDK is the right call for most teams building video into a product today — but building it the hard way, with a small team and no SDK, taught me things about real-time media that explain why those hosted SDKs are structured the way they are.

WebRTC gives you the media layer, not the product

WebRTC as a browser API handles peer-to-peer audio/video/data transport once a connection is established. It does not hand you signaling (how two peers find each other and exchange connection info), room management, or reconnection logic — all of that was ours to build. This is the part that surprises people coming in expecting new RTCPeerConnection() to be most of the work: the actual engineering effort is almost entirely in the layer WebRTC doesn’t provide.

Socket.io as the signaling backbone

Before two peers can establish a direct connection, they need to exchange session descriptions (SDP offers/answers) and ICE candidates through some out-of-band channel. Socket.io was that channel — a persistent WebSocket connection per client, with rooms mapping cleanly onto Socket.io’s own room concept for routing signaling messages to the right participants. The signaling server never touched media at all, purely connection-negotiation metadata, but it sat on the critical path for every single connection — a dropped signaling message during ICE negotiation doesn’t throw an obvious error client-side, it just produces a call that silently never connects. Logging every offer/answer/candidate exchange with enough detail to reconstruct a failed negotiation after the fact was one of the highest-leverage things I built, because “the call didn’t connect” is a nearly useless bug report without it.

STUN and TURN were not optional infrastructure

STUN servers help peers discover their public IP/port for direct peer-to-peer connection, and that works for a meaningful share of real-world network configurations — and fails for the rest. Symmetric NATs and restrictive corporate or campus networks block direct peer-to-peer connections outright, common enough among Kintry’s actual users that skipping TURN relay infrastructure would have meant the product simply didn’t work for a real chunk of them. Budgeting for TURN server infrastructure and its bandwidth cost from the start, rather than treating it as an edge case to add later, was one of the decisions that separated “works in our office testing” from “works for real users.”

Building this with a small team meant ruthless scope discipline

Leading a 10-member team across engineering, sales, and HR meant the engineering side of this project was small relative to the ambition of “build video conferencing from scratch.” The scope decision that made this achievable: full mesh topology (every peer connects directly to every other peer) for small group calls, rather than building a full SFU (selective forwarding unit) media server from day one. Mesh’s bandwidth cost per client grows with participant count in a way that doesn’t scale past a handful of people, but it was the right complexity tradeoff for where the product actually needed to be first — building SFU infrastructure before validating the product needed calls larger than mesh could handle would have been solving a scaling problem before we had the scale to justify it.

Reconnection handling mattered as much as initial connection

Real users switch networks mid-call — WiFi to cellular, one WiFi network to another — and a product that just drops the call on any network change is a bad product regardless of how solid the initial connection logic is. Building explicit reconnection handling (detecting a broken peer connection, re-running ICE negotiation to re-establish it without the user needing to manually rejoin) took real, unglamorous engineering effort, and it was worth every bit of it — this was consistently the difference between calls that felt reliable and calls that felt fragile in exactly the moments (someone stepping away from a desk, a spotty connection) that matter most for whether people trust the product enough to keep using it.

What I’d do differently, and what I wouldn’t

Building the signaling and connection layer from scratch was genuinely valuable — it forced a level of understanding of what actually makes real-time video reliable that using a hosted SDK wouldn’t have provided, and that understanding is durable, applicable knowledge beyond this one project. What I’d reconsider given the choice again: the operational cost of running TURN infrastructure ourselves at a small team’s scale was real, and evaluating a hosted TURN provider earlier, even while keeping the rest of the stack custom, would likely have freed up engineering time for other and higher priorities without meaningfully changing the product’s actual reliability.