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.

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.

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).

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.

Develop, Deploy, Disrupt.