In this presentation Tsahi Levent‑Levi debunks the notion that using WebRTC is free, explaining that while the browser‑based client stack is open‑source, the surrounding infrastructure—TURN servers, media servers, recording storage, monitoring, scaling, and the engineering talent to operate them—incurs significant operational expenses. He shows how a modest $30K proof‑of‑concept budget can balloon to $200K+ in the first year once these hidden costs are accounted for. Levent‑Levi then outlines a spectrum of build‑vs‑buy strategies rather than a binary choice, describing three common patterns: (1) buying all plumbing and building only the differentiating product layer; (2) starting with a CPaaS vendor and gradually migrating components in‑house; and (3) using an open‑source core while selectively outsourcing commercial services such as TURN. He stresses the critical first question of whether real‑time communication (RTC) is the core product or merely a feature, as this determines the appropriate pattern. Vendor selection is framed as a co‑founder relationship, with emphasis on long‑term fit, risk of re‑architecting, and the added complexity introduced by emerging voice‑AI and generative‑AI capabilities. He highlights how AI‑enabled vendors (Daily, LiveKit, Twilio, OpenAI, ElevenLabs, Cloudflare) differ in their integration points, and how infrastructure decisions (GPU usage, SFU vs direct bot connections, latency requirements) will lock in product capabilities for years. Finally, he advises that the build‑vs‑buy decision is an evolving strategy that should be revisited regularly, and offers his consulting services for companies navigating these choices.
Chapters
We'll just use WebRTC. It's free, right? Well, that's the most expensive free decision that the CTO can make. Now here's the thing: WebRTC is free. It's open source. You can go take the code, whatever you want with it. It's embedded in all web browsers today, so the browser is there and it has the implementation. You can just use that. Freely, but everything else around, around it isn't. So if you want to use a media server, you need to either pay for that for a managed service, or you need to host your own. Same for torrent servers. These are things that would cost you operational money, okay? That's maintaining them, the CPUs, the bandwidth around that, storage that comes with it if you're doing recording. All of these things cost you money. Either by a managed service or by putting these things on your own. Then there's the employees to do that, and the ops around that, and the maintenance and optimization work and testing. There's a lot of things in a free WebRTC service when you're building and implementing it that isn't really free. Now, there are a lot of hidden costs, um, and they hit after you do the POC, after that proof of concept or that demo. Turn servers, media servers, monitoring, scaling, engineers that actually know this stuff and know how it works. Once you factor all of these things in, that $30K build budget that you started with, probably with an outsourcing vendor or trying to use your own freelancer, your own team inside, that just, you know, blew up to $200,000 by the end of year 1. And that's only the first year. You're going to have more of these moving forward, more moving parts to handle, more optimizations, customer requests, complaints, new feature requests, a lot of things that come into this thing called the WebRTC application. Now the question isn't, am I going to build everything on my own or buy everything from a third party, use a CPaaS vendor, a managed service that does everything for me and I just build my application logic on top. Okay, it's more of a spectrum, it's not a binary decision. And I think if you look at it more closely, smart teams pick their battles. They would decide that they are going, for example, to take the TURN servers from a third party, use that, build their own SFUs. Or outsource the whole thing so they can deal with their application, or do that in phases, each time trying to remove something from a third party and doing it in-house. Or even the opposite, starting something in-house and then going to a third party for that. In some cases, I've seen teams that use more than a single CPaaS platform to do different parts of their service. That works too, but you need to understand what it is that you're doing. That's, I think, that's the hardest part, and it's the most important one as well. So there are 3 patterns at work here. At the end of the day, you can either say, well, you know what, we're going to build a differentiator that we have as a company and buy all the plumbing. So if you're, for example, a company that deals with healthcare, you're going to do a telehealth application. A lot of the application logic is not going to deal with the video call itself. The video part, it's there, it's important— without it there is no service— but it's almost a commodity. So getting that from a third party instead of building it on your own might make sense, okay? Because then you can focus a lot more on things that relate to HIPAA compliance on your application, dealing with the patient databases, and how to add the context that you need for that specific session where the doctor and the patient come into that visitation together. Now, in that case, you might say, I'm going to build a differentiator and then buy the plumbing of the video part. That might not be the case. Again, it depends on the type of customers that you have and what they look and expect from you. The second part pattern that works, you know, you can start with the CPaaS platform because it works for you. Take Vonage, Twilio, Daily, LiveKit, you know, Jitsi, 8x8, whatever. There are almost 20 or 30 such platforms that I can think of. You start with that CPaaS platform and then you graduate either components or everything to something that you do on your own. On top of open source. Okay, the third option is to use an open source core. That's great. And then add some commercial edge into it in specific places. Best part I try to use all the time is, well, take the TURN server and outsource it to someone else, usually Twilio or Cloudflare. Giving it to them instead of buying it your own buys you a lot of time and a lot of, you know, quiet from market and from users that are going to complain, because Twilio and Cloudflare do it really, really well. If you give it to them, you have less issues. You can decide later to bring that in-house. There is no real vendor lock-in here, so that's the easiest part to go and outsource. So 3 patterns. The first one was differentiator— you do, I buy the plumbing— which is the WebRTC infrastructure part. You can start with SIPaaS and then graduate components to your own application. So start by having everything outsourced and then bringing things in as you grow, or open source some parts and use commercial in other parts like TURN servers and the managed service. Now you need to ask yourself when you pick between these patterns, Is real-time communications your product or just a feature inside it? Okay, answering that question changes everything. A lot of companies would say, well, you know, that's core to what we do, that's important, this is our product. I had someone at some point tell me something like, I want to build an application for, uh, tourist guides that will go to Machu Picchu with a tablet and they show the people what it is that they're watching and talk to them and guide them. And people will be able to join from home because they're elders and they don't want to do the trips, the hard trips, but want to see and explore and experience these places. And I wanted to work on networks that are really, really poor, and it should be better than what Google Meet and Zoom provides today. Well, guess what? It's not going to happen. Why? Because you just defined something that you cannot build. If Zoom can't give you that type of quality of experience, or Google Meet, You probably can't either, especially if you come to me. It means that you don't know, understand WebRTC enough. Okay, now in that type of use case, if I'll go and reframe that, I would say I want to be able to build a virtual traveling solution where travel agents can go, travel guides, tour guides can go and show and explore places and show these to people. I want to build an asset of the tour guides themselves, the experiences, the shopping cart, how people watch and view that. And you know what, the actual session, that's a feature inside everything else. And my moat, my asset, my differentiator is not in the video quality. I cannot compete with others anyway because this is a bit of a niche. Okay, so you need to ask yourself and be really, really frank. Is the communication part, the real-time communication part, voice and video, is it the product or just a feature inside the product? Based on that, you'll know which of the patterns to go and use. Now, once you decide, let's say, that you're going to buy these things and not build on your own from scratch, then you need to remember that The vendor you choose is not just a vendor, it's almost a co-founder. So treat it like you're picking a co-founder, because a bad pick at this stage is going to cost you more than building from scratch. In some cases, and in some consulting engagements that I have, companies come and say, we've used Vendor X and this is our use case, and it doesn't really fit what Vendor X is giving us. What should we do? So you try and shape this so Vendor X would fit. It never works. So they find themselves needing to switch from one vendor to another. That's additional engineering work, re-architecting some of the solutions that they have, and it adds a lot of risk. So it's not only resources and budget, it's actual risk. So making that decision early on and making a good decision is really, really important. It's fundamental to how you're going to work here. So treat it as if it's a co-founder that you work with, a partner that is there for the long term, and you need it to work and be focused on your use case and your needs. Now, one more thing to remember, it's that today we're at the age of AI voice and generative AI and AI agents. You know, that's going to change everything else. And that resets the whole calculation and who the vendor that you need to work with. I'll give an example, okay? If you look at the CPaaS vendors, then Daily, Livekit, Twilio, Vonage, it's— one of them has a slightly different story in what they are doing in the voice AI space. Daily came out with Pipkit, an open source platform and framework for that. Livekit did something similar with their own Livekit agents. Twilio built the whole orchestration layer above that, including memory and connecting that to CRMs and to CDPs, the customer data protocol or whatever that is, platforms. Okay, so you've got these kind of vendors. Then you have things like OpenAI and ElevenLabs where they actually baked WebRTC into their solution. So you've got the OpenAI Realtime APIs, the ElevenLabs WebRTC interface. Cloudflare came with a solution that does like edge thingy that you can connect WebRTC to edge workers that do the work there and try to connect to their data center in the backend. And that's a new decision point that you need to take into account and factor in. So you need to be again very conscious about your decision of which vendor to choose, especially if you have voice AI in your current roadmap or somewhere in the near or midterm future. You need to figure out what works well there. Okay, so bear that in mind. Now the last thing I want to touch is that the infrastructure bets that you are making today for voice AI are going to define the product that you have for years. It's not only the vendor that you're going to pick It's deciding if you're going to use GPUs, where you're going to put this processing, are you going to use an SFU or not when you do a user-to-bot session, how you're going to scale that, how fluid you need that to be, how quickly and responsive the system needs to be, because that means choosing a vendor with a low latency for that. Is video important? One-way, two-way? Multiple participants in the same session with an AI bot, one AI agent, more than one agent per session. Okay, so these things are going to dictate the infrastructure, and this is going to also indicate which vendors would be suitable for that. So I want to end here with the fact that the build versus buy is not a one-time decision. You go, you make that decision at the beginning. And it's an important one, it's a strategic one that you're going to make, but it's not really a decision, it's an evolving strategy. You need to revisit that probably once a year, every half year, would look at that and say we're on the right track, or we need to map this and see what happens and go talk to our vendor. You need to be very conscious about that, and again, be really, really intentional in what you do there, and it's not a one-off, it's an ongoing thing. If you're looking for any assistance in this area, just come to me, bloggeek.me. I'm Tsahi Levent-Levi. I am here to help companies use and implement their applications using WebRTC.
