Two browser tabs, a signaling script, a video call. A developer can build it in an afternoon, and it runs fine on the office network. The team starts treating that afternoon as a small version of the product. In reality, it's closer to a postcard of the product.
WebRTC delivers a call between two endpoints. Everything around that call belongs to the team: signaling, media servers for group calls, relays for blocked or restrictive networks, recording, moderation, monitoring, legal requirements, and the ongoing work of keeping up with browser and platform changes. The demo skips nearly all of it.
That is what makes a WebRTC demo a trap: it proves that the core technology works while hiding most of the engineering required to make it work reliably for real users.
What the Demo Never Tests
Production has to handle the cases that the office network conveniently hides.
A media server is not a web server. Depending on the architecture, it may need a wide range of open UDP ports (many deployments allocate ports per connection, although some media servers multiplex traffic over a single port). It scales on bandwidth and packet forwarding rather than on CPU-bound request handling. And because live calls can outlast a deployment window, servers often have to drain gracefully before an update, which, for long-running sessions, can take hours.
Quality is the other blind spot. Microsoft notes that a Teams stream classified as "Poor" does not necessarily mean the user noticed a problem. Every "poor call" threshold is a vendor-defined measurement. The one useful reference point is ITU-T G.114, which addresses one-way transmission delay and treats delays below 150 ms as generally acceptable for conversational applications, with highly interactive tasks becoming sensitive at lower delays. Mobile audio causes many of the complaints that infrastructure dashboards cannot explain, including device-specific audio processing and changes in audio routes. A dashboard full of green servers can still tell you nothing about what a listener actually hears.
Relays come first. Relayed sessions, where a TURN server forwards the media because no direct path exists, can account for a significant share of WebRTC calls. One measurement published by WebRTC engineer Philipp Hancke put the figure at roughly 17–22% for the service he analyzed, while broader industry guidance says to expect anywhere from 0–50%, depending on the audience and network conditions. Corporate networks are one reason: locked-down environments may block UDP and allow traffic only through a small number of ports, making TURN over TLS on port 443 an important fallback.
Decisions That Cost the Most to Reverse
All of these decisions take shape during the demo. Each is cheap to make early and expensive to change once users, data, or partners depend on it.
Topology. Peer-to-peer (P2P) and selective forwarding unit (SFU) architectures behave differently under different loads and network conditions. A simple voice chat for ten people has very different requirements from a Twitch-like service serving hundreds of thousands of viewers. If the topology is chosen around the proof of concept rather than the actual product, scaling can force a redesign of the media layer later.
Build versus buy. Building the media infrastructure in-house means owning its development, scaling, maintenance, and upgrades. Buying shifts those responsibilities to a vendor but creates a dependency on its product, pricing, and roadmap. In March 2024, for example, Twilio announced that Twilio Video would reach end of life on December 5, 2026, then reversed that decision in October 2024 after customer feedback. A vendor can change the constraints of the architecture after the product has already been built around it.
Client stack. The client stack creates a similar long-term dependency. WebRTC's native APIs may be stable, but the surrounding build and integration work is not something a proof of concept can simply postpone. A large Chromium/WebRTC checkout is already a substantial engineering commitment before compilation begins. Private patches are normal; drift is the danger. Meta describes how its WebRTC fork had fallen "years behind" upstream and required a multiyear, dual-stack migration to escape. Patches attached through official interfaces stay relatively cheap. Edits inside audio processing, codecs, or bandwidth estimation get costlier with every upgrade.
End-to-end encryption. Add it later, and recording, transcription, moderation, and signaling may all need to be redesigned. Server-side audio mixing also stops working in its usual form when the server cannot access the media.
Moderation and recording. Real-time communication leaves no replayable evidence unless the product captures it. That capture may be needed for moderation, abuse investigation, recording, or compliance, and it raises questions about buffering, storage, retention, access, user disclosure, and privacy. At scale, moderation itself becomes a systems problem. If an automated classifier screens, say, 500,000 sessions or audio segments a day, even a 1% false-positive rate means about 5,000 incorrect flags daily, each one a potential wrongful mute, ban, or manual review. The real number depends on volume, the base rate of genuine violations, and where the detection threshold is set.
Identity and permissions. Communication permissions rarely belong to a single layer. Blocking, muting, parental controls, bans, and privacy settings may be defined by the platform, the identity system, or the voice service itself. The implementation has to carry the relevant state across those boundaries and define what happens when the layers disagree.
Telemetry ownership. Callstats.io changed hands twice in under three years: 8×8 acquired it in early 2020, and Spearline acquired the Callstats business from 8×8 in December 2022. The original callstats.io service is no longer available at its former address. Customers who kept their raw statistics only there risked losing access to that history. This is the least visible cost of outsourcing observability: your telemetry needs to outlive the vendor relationship, and the vendor may not last that long.
The Proof of Concept Is a Risk Test
A WebRTC proof of concept should answer more than whether two users can hear and see each other. It should expose the assumptions that will become expensive once the product is live.
Test the network before testing the interface. Introduce packet loss, latency, restrictive firewalls, and relay paths. Measure what happens when the direct connection fails, not just when it works.
Price the production architecture before choosing to self-host or buy. Include relay traffic, bandwidth, observability, engineering time, upgrades, and the cost of keeping old clients working. A low infrastructure bill at prototype scale says little about the economics of a live service.
Test the decisions that are hardest to reverse. Topology, client dependencies, encryption, recording and moderation, identity and permissions, privacy defaults, and telemetry ownership all deserve explicit validation before users depend on them.
Make operational ownership explicit. Give every private patch an owner. Give every critical operational task a second person who can perform it.
The final test is time. Upgrade the client stack. Replace a dependency. Revoke a credential. Roll a media server while calls are active. Assume a vendor disappears or changes its terms. If the system cannot survive those exercises, the proof of concept has not proved enough.
The work ultimately comes down to three questions: Does it connect? Does it hold? Does it stay current? A demo answers only the first. A production-ready architecture has to answer all three.
Disclaimer: The views and opinions expressed in this article are those of the author and do not represent those of people, institutions, or organizations that the author may or may not be associated with in a professional or personal capacity. All information is provided on an as-is basis.
About the Author
Mikita Hanusenka is a senior engineering leader with 10+ years of experience who built and scaled a cross-platform real-time communication platform for the gaming industry, enabling voice and video interactions for millions of concurrent users with ultra-low-latency performance. Connect with him on LinkedIn.
