The “build vs. buy” debate in telecom is different than it is in software, because voice systems require real-time media, carrier compatibility, and operational resilience that most teams underestimate. This post explains how telecom evolved from rigid on-prem systems to cloud and Communications Platform as a Service (CPaaS), why “build on FreeSWITCH” can demand major capital and deep infrastructure expertise, and why SignalWire’s Programmable Unified Communications (PUC) approach aims to make building telecom applications accessible by providing deployable building blocks plus SignalWire Markup Language (SWML) for orchestration.
Why “Build vs. Buy” Started in Business Software
I don't remember when exactly the “build vs. buy” conversation first began, but I think it started around CRM and ERP systems, picking up momentum in the SaaS era. In the early days of the internet, the choice was mostly “build vs. ‘no dice,’” because constructing any kind of web-based tool required starting from scratch. I remember developing no less than two complete web-based CRM systems using whatever I could get my hands on at the time.
Starting in the early to mid-2000's, the cloud and SaaS era brought many more tools to build applications. Things like databases and LAMP stacks became prevalent. This made creating more approachable, which made sense – that's why we built the web and why Linux emerged as a viable platform to host everything. Virtualization was starting to show up as well, opening a can of worms we are still seeing the effects of today in 2024.
At the height of the Web 2.0 era, the “build vs. buy” debate intensified as more companies chose to build tools that others would purchase rather than develop their own systems. The notable example is, of course, Salesforce, emerging from that original CRM/ERP moment. This is about the same time I decided to transform my skills in web server infrastructure to voice over IP and real-time communications.
Despite the numerous tools that were now available for various web apps, there were not a lot for telephony. Combining websites with call centers often relied on physical lines that didn't travel well over the internet. Buying expensive and rigid telephony systems was the only real choice. Building your own was the equivalent of being dropped in the jungle with only a machete to make your way.
FreeSWITCH changed what “build” could mean
There were some promising examples of IP telephony in open source, which could do interesting things with a little hardware. However, to be genuinely useful, these solutions needed to scale and contend with telecom giants. Building something compatible with existing telecom paradigms was crucial, as global communication methods varied widely. FreeSWITCH was my answer—a vision to allow everyone to build communication tools and pipelines with the focus on the application rather than the underlying infrastructure.
FreeSWITCH opened pathways towards realizing this bigger vision. It transcended the typical "build vs. buy" conversation, evolving over 18 years and giving rise to many popular telecom applications. Only the top echelon of users could elevate it to the level of Zoom Phone, Five9, Vonage, and Amazon Connect. These services made the "buy" side of the equation viable but often cost-prohibitive and rigid for smaller companies.
CPaaS made “build on top” mainstream, but voice lagged
Somewhere in the 2010s, we started to see the "CPaaS" industry appear. This complicates the equation a little with solutions you can both buy and build upon, but it was mostly focused on SMS. There was almost no telephony voice innovation in this space beyond shuffling low-quality 8kHz audio calls.
That leaves us with just a few options:
Buy rigid, expensive applications and hope they check enough boxes to be tolerable.
Build on something like FreeSWITCH from the ground up and learn how to manage a massive infrastructure, orchestrating many services as one with redundant paths and horizontal scalability. And try to match the might of the rigid application providers on your own.
This is a better position than what we had to start with. Still, the problem is that most of the time, if you decide to build, you better have a minimum of 5 million dollars, an expert engineering leader, and a team of engineers with the necessary skills to build out the underlying components and get it right the first time so that price doesn’t go up. Then, you still need to make your application on top of that infrastructure. The main danger is that this sounds like fun to any software engineer, so they will undoubtedly be ecstatic and eager to offer up how easy it will be (remember, 18 years and counting).
Why Programmable Unified Communications (PUC) is the way
While it might sound like I’m making a case to “buy” here, the whole point is that being able to “build” should be accessible for a greater audience. The reason I decided to put my effort into building SignalWire with our team is to suffer this pain once and move the requirements to something within range of the typical small-to-medium technology company. We want to see companies build what they envision, and potentially become a “buy” option for others.
This is the entire mindset behind Programmable Unified Communications (PUC) as a category and the Call Fabric Stack that SignalWire has pioneered. We build the hard stuff so others can build the easy stuff on top of it, simplifying how we can build and distribute telephony applications in the same way that the World Wide Web simplified the creation of powerful apps.
I write this blog now from a window in a web browser and haven't had a local word processor since forever. Not only are the paradigms similar, but they also overlap directly, adding the web as one of the key onramps for communications.
Imagine giving a URL out instead of a phone number that leads to all of your devices with an AI voice assistant who can take your calls when you are busy. Or creating your own hybrid call center, PBX, or public phone system integrated with your business logic. Or creating a powerful application suite to sell to the SMB market as an alternative to expensive phone lines.
The first step is taking larger building blocks and making them easy to deploy and simple to wire together so you can call them from phone numbers, the web, or VoIP systems like FreeSWITCH. Blocks like video conference rooms, call queues, or user accounts can be arranged and assigned addresses of varying types via UI or REST APIS.
Any smaller details can be managed with SignalWire Markup Language (SWML), a markup language implemented as a data structure in JSON or YAML, allowing for flexible public and private endpoints. This allows you to:
Record calls and forward them
Implement classic voice menus or more modern AI Agents
Create call flows that can be scaled to any number of concurrent calls
To demonstrate the power of SWML, Chris Rienzo, VP of Engineering at SignalWire, created a serverless IVR set up with call screening, voicemail functionality, and time of day routing. Creating this same IVR system without SWML (using something like FreeSWITCH) would require building and deploying a server, setting up and maintaining the OS, keeping FreeSWITCH up to date, and developing the supporting applications to run against the server to implement the IVRs. With SWML, it took Chris only an hour to get the serverless implementation up and running at scale.
Ultimately, my journey through the jungle of building telephony systems aims to pave the way for the next generation of developers to build more easily. By simplifying the technology, we hope to scale it globally and challenge the first-generation telecom networks that carriers cling to so that more devs can build and experiment.
Frequently asked questions
Why is building telecom infrastructure so expensive compared to typical software platforms?
Telecom requires real-time media handling, routing, reliability under concurrency, and compatibility with carrier and Voice over IP (VoIP) paradigms, which often forces teams to build and operate a large multi-service system, not just an application layer.
What does “build on FreeSWITCH” usually mean in practice?
It typically means you own the infrastructure and operational complexity, including scaling, redundancy, upgrades, and orchestration across multiple components, then you still build the product on top of that foundation.
Why do cloud communications products feel rigid even when they are easy to buy?
Many packaged systems are optimized to be broadly usable and easy to deploy, but that often limits how deeply you can customize call control and workflow logic without hitting platform constraints or cost ceilings.
What is Programmable Unified Communications (PUC)?
Programmable Unified Communications (PUC) is an approach that provides larger building blocks for voice, messaging, video, and user objects, then lets teams compose and orchestrate those blocks into custom applications without building the underlying telecom stack from scratch.
What is SignalWire Markup Language (SWML), and when would you use it?
SignalWire Markup Language (SWML) is a JSON or YAML-based markup used to define call behavior and orchestration, such as recording, forwarding, Interactive Voice Response (IVR) menus, and AI agent flows, without deploying and maintaining a full telephony server stack.
