If you want to build your own remote collaboration tool rather than subscribe to one, the work is done by WebRTC engineering teams. These split into two practical groups. The first is specialized firms that have shipped real-time video products before and own the build end to end, including Ecosmob, WebRTC.ventures, Fora Soft, and Frozen Mountain.
The second is internal product teams assembling the application on top of a video SDK platform like Daily, LiveKit, Agora, or Vonage Video API. The off-the-shelf products people usually mention here, Zoom, Microsoft Teams, Loom, Whereby, and CoScreen, are tools you buy, not tools you build. The distinction matters because the reasons to commission a build are specific, and most teams asking this question have already tried the off-the-shelf path and found it didn’t fit.
Why anyone builds this when ready-made tools exist
The first useful filter for picking a builder is understanding why a build is on the table at all. In our experience the reasons fall into four buckets, and the right team for each is different.
- Embedded video inside another product: A telehealth platform, an edtech app, a remote inspection tool. The collaboration experience needs to live inside an existing UI, share authentication with the host app, and write structured data (consult notes, lesson recordings, inspection findings) into the host product’s database. Generic Zoom integration breaks the experience. This use case usually goes to a CPaaS or video SDK provider, sometimes wrapped by an agency.
- Regulatory or data residency requirements: Healthcare under HIPAA, financial services with recording retention rules, government tenants requiring sovereign cloud, or any deployment in a jurisdiction where SaaS data flows are a problem. SaaS products can satisfy some of these on paper but not all of them in practice. This case typically goes to a specialized WebRTC firm that can deploy on the customer’s infrastructure.
- Cost economics at scale. CPaaS pricing is fine at low and medium volumes. At a few million minutes per month it starts to dominate the P&L, and at that point a self-hosted SFU on cloud infrastructure costs a fraction of the per-minute rate. Teams that crossed this threshold (often around the 200,000-monthly-active-user mark, though it depends on session length) commission a build to escape the meter. This usually goes to a specialized firm with operational experience running media servers.
- A genuinely different product: CoScreen lets multiple people control a shared screen simultaneously, which platforms like zoom, microsoft teams cannot do. Around uses small floating video bubbles instead of a grid. Krisp built a noise-cancellation product and only later added meetings. If the product hypothesis is something ready made products architecturally cannot become, no amount of integration solves it and a build is the only path.
What HD video, screen sharing, and recording actually cost to engineer
The three features in the question look similar but pull engineering in different directions. The clearest signal of a competent build partner is whether they can talk specifically about each.
- HD video requires a Selective Forwarding Unit. Peer-to-peer WebRTC works for two participants. Beyond that, you need an SFU. The honest open-source choices are mediasoup, Janus, Jitsi Videobridge, and LiveKit (which is also available as a managed service). The SFU choice determines mobile SDK availability, recording integration, simulcast behavior, and how scaling works. A build partner who doesn’t have a strong opinion on this has not shipped at scale.
- Screen sharing is easy to add and hard to get right. Browsers expose the getDisplayMedia API. The track comes back. The problem is that default settings produce blurry, unreadable screen-share. Production builds run screen-share at higher resolution than camera video, lower frame rate (usually 5 to 10 fps for static content), and with contentHint set to either ‘text’ or ‘detail’ so the encoder doesn’t smooth out fine detail. None of this is hard to implement once you know it, but most agencies don’t know it on day one.
- Recording is where teams underestimate scope. There are three architectures and they produce different outcomes:
- Client-side recording uses the browser’s MediaRecorder API. Cheap, highest local fidelity, but only captures one perspective and breaks if the recorder closes their tab.
- Server-side track recording stores each participant’s stream separately on the media server. Required for compliance use cases that need original tracks. Storage costs are linear in track count.
- Composite recording runs a headless Chromium instance that joins the call, renders the layout, and captures it with FFmpeg. This produces the Zoom-style single MP4 most users expect. It is also the most expensive option to operate, consuming roughly a vCPU and several hundred megabytes of memory per concurrent recording. At 100 concurrent recorded sessions that is real money.The recording architecture choice should come up in the first technical conversation with any builder. If it doesn’t, that’s the signal.
Who builds, and what each kind of team is good at
- Specialized WebRTC engineering firms. These teams own the build end to end including media server selection, recording pipeline, mobile clients, and ongoing operations. Right when ownership and control matter, when the deployment needs to be self-hosted or hybrid, or when SIP interop with legacy room systems is in scope. WebRTC.ventures, Fora Soft, and Frozen Mountain are commonly cited in this segment. Ecosmob operates here too, with WebRTC development alongside multi-tenant conferencing platform builds. Typical engagement is four to nine months for a first release and ongoing for operations.
- Video SDK and CPaaS providers (used by your own team or an agency). Daily, LiveKit, Agora, Vonage Video API, and 100ms give you the media plane as a managed service. You build the application on top. Fastest path to a working product, often two to eight weeks for a v1. The tradeoffs are per-minute pricing that scales with usage and dependence on the provider’s roadmap. Twilio’s decision to sunset its Programmable Video API in late 2024 is a useful reminder that lock-in is a real risk in this category, not a vendor talking point.
- General software agencies layered over open-source. An agency without deep WebRTC backgrounds can still deliver a working tool by deploying Jitsi Meet, integrating a video SDK, or using a library like Simple-Peer for peer-to-peer. Right for internal tools, MVPs, or products with predictable low-volume use. Tends to hit walls when call quality at scale, TURN server economics, or recording reliability become real engineering problems.
Two questions that filter builders quickly
Once you have a shortlist, the fastest way to separate builders who have shipped this from builders who have not is to ask two questions in the first call.
First, how do you handle the 30 percent of users behind symmetric NAT? Symmetric NAT breaks direct WebRTC connections and forces traffic through TURN servers. According to the IETF’s WebRTC NAT guidance (RFC 8835), TURN relay is required for a meaningful share of real-world connections. A team that’s run this in production will answer with specifics about coturn deployment, regional TURN allocation, and bandwidth costs. A team that hasn’t will give a generic answer about “NAT traversal.”
Second, walk through what happens if the composite recorder crashes mid-session. Where do partial recordings live? Is the call interrupted? How quickly does a replacement recorder rejoin? Is the user told? Production teams have lived this failure mode and have answers ready. Teams who haven’t shipped recording at scale will improvise.
