Last year I was the engineering lead at a B2B SaaS that was supposed to do "smart calling" for outbound sales teams. Click-to-call from the CRM, AI transcription, call routing based on lead score, the usual stack you'd expect in 2024.
We chose a major CPaaS provider because nobody gets fired for picking the obvious one. The docs were great, the SDK worked in twenty minutes, and the pricing calculator told us we'd spend around $2,400 a month at our projected scale.
Nine months later, we were burning $14,000 a month, our call quality was degrading during our biggest customer's peak hours, and I was on a call with a custom VoIP development company explaining why we needed to migrate. This is the story of what went wrong, what I should have caught earlier, and what I'd do differently if I were starting over.
The first six months looked fine. We integrated their voice API for outbound calls, used their programmable calling SDK for the dialer logic, hooked up their conversation module for transcription, and stitched it all into our React frontend with the JS SDK. Our first big customer onboarded with 80 seats. By month three we had 600 seats across 14 companies. Our AWS bill was reasonable. The CPaaS bill was about $4,000 a month, not bad.
Then we started hearing about "the slowdown." Our biggest customer, a 200-person inside sales team, was telling us that calls between 2pm and 5pm Eastern were getting lower call quality. Latency was up. Some calls were dropping. Their VP of Sales was getting calls about it.
I spent two weeks chasing it. Our backend was fine. Our React app was fine. Our network was fine. The only common factor was the CPaaS layer. We opened a support ticket. They told us our usage profile was "inconsistent with optimal performance" and suggested we move to a higher-tier SIP trunk. The higher-tier trunk would have moved our monthly cost from $4,000 to about $9,000.
That was the first crack
The second crack came when we tried to add custom features. The CRM team wanted call recording stored in our own S3 buckets with custom retention policies. The CPaaS recording storage was fine for compliance, but we couldn't run our own ML models against the recordings without pulling them out and re-uploading them. The serverless function tier had hard limits that meant we were running half our call control logic in our own AWS Lambdas anyway, which added latency we couldn't optimize.
The third crack was the contract terms. As we grew past 800 seats, we needed predictable per-call costs to model our gross margins. Their pricing scaled in ways that didn't map cleanly to our unit economics. Every percentage point of margin compression hit our Series B forecasts.
That's when I started looking into what a custom VoIP development company actually does, and whether building on Asterisk or FreeSWITCH instead of a CPaaS would solve our problems.
What I learned during that research phase changed how I think about VoIP infrastructure
Building on FreeSWITCH, Asterisk, or Kamailio is not the same as building a VoIP company. You're not trying to become a phone company. You're building a piece of your product that happens to use VoIP protocols. The question isn't "can we build this?" It's "do we have the protocol-level expertise in house to debug it when it breaks at 2am during our customer's peak hour?"
The honest answer for us was no. None of our six engineers had ever written a Kamailio config file or debugged a SIP trace. Hiring someone full-time who had would cost us about $180,000 plus equity, and we'd still need at least two of them for redundancy.
That's the actual value of working with a specialist VoIP team. You're not buying code. You're buying production debugging experience that takes 5 to 10 years to accumulate. You're buying the engineer who's already seen the specific NAT traversal failure that's about to take down your platform, and knows exactly which RTPEngine flag fixes it.
We engaged a team that built a custom VoIP stack on top of FreeSWITCH and Kamailio. They handled the SIP trunk negotiations with our carrier directly, which saved us about $3,000 a month in trunk costs alone. They set up our own RTPEngine cluster for media handling, which dropped our call quality complaints by 92%. They built our recording pipeline directly against our S3, eliminating the round-trip we'd been doing through the CPaaS cloud.
The migration took about four months. The cost was a one-time build plus ongoing maintenance retainer, which together came out cheaper than our previous CPaaS bill within seven months.
Here's what I'd tell my past self
CPaaS is not wrong. It's a great fit for the first 12 months when you don't know what your call volume looks like, what your customers will actually demand, or whether your product will even work. The mistake we made wasn't choosing a CPaaS. The mistake was not knowing what the migration signals were, and not having a plan for what comes after CPaaS when your unit economics or feature requirements outgrow it.
The questions to ask yourself are simple. Are you paying more than $8,000 a month in CPaaS fees? Do you have feature requirements that don't map to your provider's API? Is call quality becoming a customer complaint? Are your unit economics getting worse as you scale instead of better? If two or more of these are true, it's probably time to talk to people who build custom VoIP infrastructure for a living.
The decision isn't between CPaaS and DIY. It's between renting infrastructure that someone else has optimized for the general case, or bringing in engineers to build infrastructure optimized for your specific case. Both are valid. Which one is right for you depends on where you are in your scale curve.
If you're staring at a growing CPaaS bill and wondering whether there's a better way, there usually is. Just make sure you talk to engineers who've shipped VoIP infrastructure at scale before, not generalist dev shops who think they can figure it out.
For what it's worth, the team we ended up working with is Hire VoIP Developer, a B2B custom VoIP development company that handles Asterisk, FreeSWITCH, Kamailio, OpenSIPS, and WebRTC builds end to end. There are other good ones out there too. The important thing is that you're working with people who've already debugged the failure modes you're about to hit.
Top comments (0)