WebRTC communication platform with 80% lower SDK costs and 50% less latency

The situation

A startup building a product that required embedded real-time communication had evaluated Twilio, Agora, and Daily.co for video and audio. All three had per-minute or per-participant pricing that made the unit economics unworkable at their projected scale — the cost would exceed their customer revenue per seat at any reasonable usage level. They also had a hard requirement that conversation data not transit third-party infrastructure for compliance reasons.

A junior developer had prototyped a WebRTC solution but run into NAT traversal failures — connections worked on the same network but broke for participants behind firewalls or on corporate networks. The prototype also had no persistence (closing the tab ended the session permanently) and no room management.

NAT traversal is where most self-built WebRTC prototypes stall, and it's also the part vendors don't let you see — a managed SDK just works until it doesn't, with no visibility into why a specific connection failed. The startup needed both the cost structure of self-hosting and a level of control over the connection layer that no managed vendor was going to offer.

What we built

WebRTC peer-to-peer signalling layer

A Node.js signalling server using Socket.io manages the WebRTC offer/answer/ICE candidate exchange. The signalling server is stateless in terms of media — it only coordinates the handshake and then gets out of the way. Media flows peer-to-peer or through TURN when NAT traversal requires it, not through our servers.

coturn TURN/STUN infrastructure

A self-hosted coturn server handles NAT traversal for participants behind restrictive firewalls. STUN handles the common case (direct peer-to-peer). TURN relay handles the hard cases. Deploying our own TURN server rather than using a managed service eliminated the per-relay-minute cost and kept media traffic within our infrastructure boundary.

Room and session management

Persistent rooms with access codes, waiting room queue for participants before the host admits them, session recording to S3 (audio/video), and replay on the platform. Participants who accidentally disconnect can rejoin a session in progress. Room state persists even if the host momentarily drops — the session doesn't end until explicitly closed.

Text chat and screen sharing

In-session text chat using the WebRTC data channel (not a separate Socket.io connection) — lower latency and no additional server load. Screen sharing uses the browser's native `getDisplayMedia` API, surfacing as an additional video track alongside the camera feed.

React embedded component

The entire communication interface is packaged as a React component that accepts a room ID and user token. The host product integrates it with four lines of code. Theming is via CSS custom properties so it matches the host product's design.

Monitoring connection quality in production

WebRTC connections can degrade in ways that are invisible until a call quality complaint arrives, so the platform logs connection type (direct vs. TURN relay), packet loss, and round-trip time for every session. That data let the team distinguish real infrastructure issues from a participant's own poor network — a distinction they had no way to make with the original prototype.

Results

• ~50% reduction in communication latency vs. the third-party SDK prototype
• ~35% improvement in connection stability (NAT traversal success rate)
• ~80% reduction in SDK/infrastructure costs vs. per-minute third-party pricing
• NAT traversal failure rate (the original prototype's core problem) reduced to under 2%
• Data sovereignty requirement met — no conversation media transits third-party infrastructure

Where this fits

This build is part of our web development practice, with the self-hosted TURN/STUN and connection monitoring work overlapping our cloud & DevOps practice. Products with compliance or data-residency requirements around conversation media are also where our cybersecurity team gets involved early, before the architecture is locked in rather than after.