The prototype worked on the first try. Two laptops, a sample app, faces on screen inside an afternoon.
That is the problem. It worked because almost nothing was being tested.
Both machines were on the same office network, behind the same router, with no firewall between them, on a connection that never degraded, in browsers that were already open and focused. Production video has to survive the exact opposite of all of that, and the gap between the two is where the schedule goes.
What the afternoon demo actually proved
It proved the API works. That is worth knowing and it is roughly all it establishes.
Here is what a same-network demo does not exercise: NAT traversal of any difficulty, corporate firewalls, mobile carrier networks, connections that change mid-call, bandwidth that fluctuates, devices that get unplugged, browsers that background the tab, permissions that get denied, more than two participants, and anything at all about what users see when something goes wrong.
The engineering work is almost entirely in that list. This post is about the schedule that list represents. There is a separate and equally real set of questions about the commitments that come with the integration — pricing model, data residency, lock-in — which are commercial rather than technical, and which deserve their own analysis.
Four categories consume the calendar. They are the same four on every project.
The four things that eat the schedule when you add video to an app
1. Getting connected at all
WebRTC attempts a direct connection between endpoints. On a home network that usually works. On a corporate network it frequently does not — symmetric NAT, blocked UDP, firewalls that permit nothing but outbound TCP on 443.
The fix is a relay, and roughly one session in five needs a relay based on the only substantial public measurement available, which is itself a decade old. Standing that up means deploying TURN servers, placing them near users, issuing short-lived credentials per session, and configuring TLS on 443 for the strictest networks. None of it is in the quickstart — it sits alongside the parts the quickstart skips generally.
This is also the category with the worst failure mode, because it fails silently on exactly the networks your enterprise customers use. The demo that worked in your office is the demo that fails in theirs.
2. Surviving a network that changes
A real call lasts longer than a network stays still. Users move from wifi to cellular, walk out of range and back, resume from a laptop that slept, sit on a train through a tunnel.
Each of those requires the connection to renegotiate rather than die — ICE restarts, re-offer and re-answer, and application state that survives a media path that briefly does not exist. Getting this right is unglamorous, hard to test, and impossible to skip, because from the user's perspective a call that does not recover is a product that does not work.
3. Devices, permissions and the browser itself
Camera and microphone access is a permission prompt that users deny, dismiss, or granted once to a different device that is no longer plugged in. Headsets get connected mid-call. Laptop lids close. Mobile browsers background the tab and suspend the video track. Autoplay policies block audio until the user interacts.
Every one of these is a state your application has to handle explicitly and a UI state someone has to design. There is no clever architecture that removes this work; it is a long tail of small cases, and long tails take time.
4. Degrading gracefully instead of failing
Networks get worse during calls, routinely. The infrastructure handles this by reducing quality — dropping resolution or frame rate — which is the correct behaviour and looks like a bug to users if nothing explains it.
The engineering is partly in configuration and partly in interface: what does a degraded participant look like, what does the user get told, and what can they do about it. Teams consistently discover this last, after shipping, from support tickets.
There is a fifth item that is not engineering work at all but changes the estimate more than any of them.
The third participant changes the architecture
Two-party video can go peer to peer with no server in the media path. Add a third person and every participant must send their stream to every other participant, which the client cannot sustain past four or five people. At that point you need a media server, and what an SFU is and why you need one becomes a prerequisite rather than an optimisation.
This matters for planning because it is a step change, not a gradient. "Two-person calls" and "small group calls" sound adjacent on a roadmap and are separated by an entire infrastructure component, with its own deployment, scaling behaviour and bill.
If group calling is anywhere in your first year, scope it now rather than discovering it at the third participant.
A scope table you can plan against
The ranges below are planning estimates, not measurements — no public dataset on WebRTC integration timelines exists, and anyone quoting one precisely is guessing with more confidence than the evidence supports. They assume one competent engineer who has not built video before. Treat them as relative weights rather than absolute truth.
The shape is the point, not the arithmetic. The capability that took an afternoon is one row. Everything else is the project, and every other row is invisible in a demo — which is precisely why estimates built from demos come in low, consistently, in the same direction.
What this changes about the build-or-buy decision
Most build-versus-buy analyses compare licence cost against engineering cost, and get the engineering side wrong because they estimate it from the part that is easy to see.
The more useful question is which of those rows you actually want to own. Some are genuinely yours: how quality degradation appears to users, how your application handles an interrupted call, what the experience is on the devices your customers use. Those are product decisions and outsourcing them produces a generic product.
The rest — TURN deployment, ICE restart handling, browser quirk accumulation, media server scaling — is undifferentiated. It is identical in every video product ever built, it never appears in a pitch, and it is where most of the calendar goes.
A sound decision buys the undifferentiated rows and builds the ones your users would notice. Buying everything produces something indistinguishable from a competitor using the same vendor; building everything spends a quarter on NAT traversal that no customer will ever thank you for.
Build, Buy, or Deploy
Three routes, with the honest boundary on each.
Build on open source
mediasoup, Janus, Pion and LiveKit are free, production-grade and well documented. Building on them is the right call when video is your product rather than a feature of it, or when you have constraints — regulatory, network, deployment — that no vendor satisfies. It means owning every row of that table, including the ones nobody will notice until they break.
Buy a cloud video API
Per-minute providers hand you most of the table on day one, which is a genuine acceleration and usually the fastest path to a shipped feature. The limits are that you inherit their behaviour where you might have wanted your own, and that the pricing model is linear in usage while your costs may not be.
Deploy a commercial platform
The middle path runs a commercial platform on infrastructure you choose. Samvyo is one such option: based on SFU architecture, shipping embeddable SDKs, with the media path, TURN and recording kept on infrastructure you control. The relevant part for this decision is that the undifferentiated rows — relay, scaling, reconnection — come solved, while deployment and data path stay yours. It is resilient by design rather than something you assemble.
Where it does not fit: for a two-person calling feature that will never need a media server, a per-minute API is simpler and cheaper. And if you have in-house WebRTC expertise already, building gives you control a platform cannot.
The Bottom Line
The afternoon demo proves the API works and almost nothing else. It runs on one network, with two participants, on devices that behave, over a connection that never changes — which is the opposite of production on every axis.
Scope the work from the failure cases rather than the happy path: connectivity on hostile networks, reconnection, device churn, graceful degradation, and the media server that a third participant makes mandatory. Then decide which of those you actually want to own, because owning the undifferentiated ones is where the quarter goes.
What's Next
The companion technical piece, everything that runs between two video tabs, walks the components behind each row of that table. For the commercial side of the same decision — pricing model, data residency, lock-in — what integrating a video SDK commits you to covers ground this post deliberately leaves alone.
Frequently Asked Questions
How long does it take to add video to an app?
A working two-person prototype takes an afternoon. A production feature that handles corporate networks, reconnection, device edge cases and group calls is a multi-month project for an engineer who has not built video before. The prototype exercises roughly one row of the work; the remaining rows are the schedule.
Why does the WebRTC demo work but production video fail?
Because a demo on one network skips the hard parts. Both machines sit behind the same router with no firewall between them, on a stable connection, in focused browser tabs. Production has to survive symmetric NAT, corporate firewalls, mobile carriers, connections that change mid-call, and devices that get unplugged — none of which the demo touches.
Do I need a media server for video calls?
Not for two participants — those can connect peer to peer with no server in the media path. From three upward, each participant would have to send their stream to every other participant, which client uplink and CPU cannot sustain past four or five. At that point a media server becomes a requirement, and it is a step change in architecture rather than an incremental addition.
What is the most underestimated part of a video integration?
Connectivity on networks you do not control. It needs TURN relay infrastructure, it affects roughly one session in five, and it fails silently on exactly the corporate networks where enterprise customers sit. Reconnection after a network change is a close second, because it is hard to test and invisible until a real user walks out of wifi range.
Should we build video ourselves or use an SDK?
Split the work rather than the decision. Build the parts users would notice — how degradation appears, how an interrupted call behaves, what the experience is on your customers' devices. Buy the undifferentiated parts: relay infrastructure, media server scaling, ICE restart handling, browser quirk accumulation. Those are identical in every video product and consume most of the calendar.
How much does it cost to add video to an app?
Two separate bills. The engineering cost is the scope described above, dominated by the failure cases rather than the feature. The running cost depends on your pricing model and workload shape, and on whether you pay per participant-minute or for the infrastructure directly — a different analysis with different variables.
Can a commercial platform remove all of this work?
Most of it, not all. Relay, scaling, reconnection and browser handling come solved with a platform such as Samvyo, which also keeps the media path, TURN and recording on infrastructure you control. What stays yours is the product layer — what users see when quality drops or a call interrupts — and that is the part worth keeping.
