If you're doing telehealth app development, the video layer is the single highest-stakes architecture decision you'll make. Get it right and consultations "just work" on a patient's shaky 4G connection. Get it wrong and you're debugging dropped calls in production while a doctor waits on a black screen. The choice almost always comes down to two paths: lean on a managed service like Twilio, or build directly on WebRTC. Here's how to reason about it.
The two paths, in one paragraph
WebRTC is the open, browser-native protocol that actually moves the audio and video. It's free, standardized, and already baked into every modern browser and mobile OS. Twilio Video (and peers like it) is a managed platform built on top of WebRTC — it wraps the protocol in SDKs, servers, and infrastructure so you don't have to run any of it yourself. So this isn't really "Twilio or WebRTC." It's "let a vendor operate WebRTC for you" versus "operate it yourself." That framing matters, because the trade-off is about who owns the operational burden.
What WebRTC gives you for free — and what it doesn't
Raw WebRTC handles the hard media problems out of the box: it negotiates codecs, adapts bitrate to network conditions, and — critically for healthcare — encrypts every stream with mandatory DTLS-SRTP. There is no unencrypted mode. That's a genuine head start on compliance.
What WebRTC does not give you is everything around the media:
A signaling server. WebRTC deliberately leaves signaling undefined. You build the exchange of session descriptions and ICE candidates yourself, usually over WebSockets.
NAT traversal. Peers behind firewalls can't connect directly. You need STUN and, for the ~10–20% of connections that fail P2P, TURN relay servers (e.g., self-hosted coturn) that you provision, scale, and pay bandwidth for.
Scale. Pure peer-to-peer WebRTC falls apart past a few participants because each peer sends its stream to every other peer. Anything beyond a 1:1 visit needs an SFU (Selective Forwarding Unit) — a media server like mediasoup, Janus, Jitsi, or LiveKit that routes streams efficiently.
So a minimal 1:1 doctor–patient call is very achievable on plain WebRTC. A group visit, a clinician-plus-interpreter session, or a "provider drops in on a triage nurse" flow means you're now running media servers. That's real infrastructure.
A stripped-down signaling handshake looks deceptively simple:
jsconst pc = new RTCPeerConnection({ iceServers });
stream.getTracks().forEach(t => pc.addTrack(t, stream));
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);
socket.send(JSON.stringify({ type: "offer", sdp: offer }));
The 20 lines above are the easy part. The pager-at-3am part is TURN capacity, reconnection logic, and packet-loss handling on real mobile networks.
What Twilio abstracts away
Twilio Video collapses that entire list into a managed service: global signaling, TURN relays, an SFU for group rooms, recording, and native SDKs for web, iOS, and Android. You write application logic; Twilio runs the media plane. For a small team, that can compress months of infrastructure work into days, which is often the deciding factor early in telehealth app development when you're racing to a compliant MVP.
There's a catch worth knowing before you commit. In late 2023 Twilio announced it would sunset Programmable Video, then extended the deadline, and in October 2024 reversed course entirely — publicly committing to keep Video as a standalone product and invest in it. As of Twilio's latest official word, it's here to stay. But that whiplash is itself a data point: when you're building a regulated product with a multi-year lifespan, vendor commitment and migration risk are legitimate evaluation criteria, not paranoia. Design your media layer so the provider sits behind an abstraction you control, and swapping it later is an inconvenience rather than a rewrite.
The healthcare layer both paths must satisfy
Encryption in transit is necessary but nowhere near sufficient for HIPAA. Whichever path you pick, you're responsible for:
A signed BAA. Any vendor that touches Protected Health Information must sign a Business Associate Agreement. Twilio signs BAAs; so do Amazon Chime SDK, Daily, and Zoom Video SDK. If you self-host WebRTC and the media never leaves infrastructure you control, the BAA surface shrinks — but your TURN provider and any cloud host still count.
Clean signaling. Never log PHI (patient names, appointment reasons) in signaling metadata or ICE traces.
Access controls and audit trails. Time-boxed room tokens, identity verification on both ends, and tamper-evident logs of who joined which consultation and when.
Data residency and retention for any recordings, which become part of the medical record.
Neither Twilio nor WebRTC makes you compliant. They just change where the compliance work lives.
The middle ground most teams actually pick
The real market isn't binary. Between "all Twilio" and "raw WebRTC from scratch" sit options that are often the sweet spot for telehealth:
Open-source SFUs — LiveKit, mediasoup, or Janus give you WebRTC scale without writing a media server from zero. LiveKit in particular offers both self-host and a managed cloud, so you can start managed and repatriate later.
Other BAA-signing managed providers — Amazon Chime SDK, Daily, and Zoom Video SDK are all HIPAA-eligible and reduce Twilio-specific lock-in.
For most funded consumer telehealth apps, a managed provider behind a thin internal abstraction is the pragmatic start. For platforms with heavy volume, tight margins, or strict data-control requirements, a self-hosted SFU pays off as you scale.
The cost curve nobody warns you about
Pricing is where the two paths diverge hardest over time. Managed providers bill per participant-minute, which is wonderful at low volume and brutal at scale — a platform doing thousands of concurrent visits can watch its video bill outrun its entire cloud spend. Self-hosted WebRTC flips the shape: high fixed cost up front (media servers, TURN bandwidth, on-call engineering) but a marginal cost per call that trends toward negligible. The crossover point is real and worth modeling early. Many teams launch on a managed service to hit the market fast, then migrate the media plane to a self-hosted SFU once volume makes the per-minute math painful — which is exactly why that thin abstraction layer around your provider isn't optional.
A decision framework
Reach for a managed service when speed to a compliant launch matters more than per-minute cost, your team is small, and you'd rather buy reliability than build it. Reach for self-hosted WebRTC (with an SFU) when you have media-engineering talent, need full control over data residency, or your usage is high enough that per-minute pricing dwarfs the cost of running your own infrastructure. And regardless of which you choose, wrap the provider in your own interface from day one — the teams that regret their video stack are the ones who let a vendor's SDK leak into every component.
Bottom line
Twilio versus WebRTC is really a build-versus-operate decision dressed up as a technology comparison. WebRTC is the engine either way; the question is whether you want to run the garage. Start by mapping your constraints — team skills, compliance surface, scale, and budget — then let those pick the path. In telehealth app development, the video layer you can change your mind about later is worth more than the one that looks cheapest on day one.
Top comments (0)