When we stood up an outbound sales operation, we needed a CTI — a phone system. Outbound and inbound calls, call recording, transcription, AI summaries of conversations, automated dialing through call lists — the feature set that cloud CTI SaaS products sell.

Normally this is a SaaS-selection moment. There are several good products, typically priced from a few thousand to over ten thousand yen per seat per month. Even for a team of a few people that adds up to hundreds of thousands of yen a year — but by conventional wisdom, still far cheaper than building. Telephony is a domain where failure is not tolerated and specialist knowledge is assumed. “Build your own CTI” was, until recently, not even worth considering.

This time, I built it. On Twilio and Cloudflare Workers: a WebRTC softphone, inbound and outbound calling on a Japanese 050 number, dual-channel recording, transcription with speaker separation, LLM-generated call summaries and next-action extraction, auto-dialing with voicemail detection, and embedding into our own sales management tool. The sales team uses it every day. From starting work to the first real sales call took a few weeks.

This article is not a “look what I built” piece. It is an accounting of where AI-driven development has moved the Build vs Buy break-even point — and what has not moved.

What broke in the cost structure on the Build side

The traditional Build vs Buy math went like this:

  • Buy: setup fee + seats × monthly. Works immediately. No customization.
  • Build: development from several million yen + maintenance staff. Full freedom. Months to completion.

AI-driven development broke two of those assumptions.

First, the order of magnitude of development cost. With coding agents as the baseline, a domain like CTI — a mature problem plus API composition — takes shape very quickly. Twilio absorbs the genuinely hard telephony; what remains is webhook state management and UI. This is the textbook case of what I wrote earlier: agents excel at reproducing well-precedented patterns. Work that would be quoted in the millions of yen as contract development lands in a different bracket in actual effort.

Second, the running-cost structure. Per-seat pricing disappears; what remains is Twilio’s usage-based billing (call minutes) and the marginal cost of edge infrastructure. As I wrote previously, server operations on edge platforms are close to nonexistent. The in-house version therefore has a structure where adding seats adds no fixed cost — the gap versus SaaS widens as the team grows.

The break-even framing is simple: annual SaaS cost versus initial build effort plus usage fees. That crossover used to sit at “companies with very large seat counts.” It has now moved down to where even a team of a few people can plausibly cross it.

But the true cost of building shows up in operations

Here is the part I most wanted to write. The cost of building is not paid in development. It is paid in operations.

Run the thing in production and incidents happen. Real examples:

  • A report of “poor call quality” led me to analyze recordings channel by channel. The cause was not the line but background noise on the speaker’s side — resolved through to deploying noise suppression
  • For “I can’t hear the other party,” the call itself connected and both voices were on the recording; the cause sat in one specific browser’s audio playback layer. Isolating it meant building automatic call-quality diagnostics with self-repair
  • We discovered missed inbound callbacks, and I implemented inbound routing the same day — ring all available members, fall back to the office line on no answer

With SaaS, these go to a support desk. When you build, you are the support desk. Tip into Build while overlooking this, and the money saved on development gets paid back in operational chaos.

That said, AI-driven development helps here too. Every incident above went from investigation to a production fix within a day to a few days, because incident response itself is accelerated by agents. And there is a second-order value in being able to fix things at all: when the field says “we wish it worked like this,” a SaaS request becomes a ticket into the void, while an in-house system ships the change the same day. In practice, half of this CTI’s features grew out of field reports after launch.

When Buy is still the right answer

Distilled into criteria:

Buy remains correct when:

  • The workflow is not part of your differentiation and standard usage suffices
  • No one in-house can own the system when it goes down
  • You do not want to carry telecom/security compliance yourself

Build has become realistic when:

  • You want deep integration with your business processes and existing systems (for us, embedding into the sales tool was the decider)
  • You want call data flowing into your own data platform and AI pipelines
  • Seats and usage are high enough that a usage-based structure alone changes the economics
  • Your requirements do not fit inside a SaaS’s standard feature set

And the biggest variable is neither features nor price: whether someone who can design and operate an AI harness is in-house or within reach. Without that person, the operational costs above pass critical. With them, the Build side of the ledger is far wider than conventional wisdom allows.

Build vs Buy is no longer a question of which is cheaper

The change AI-driven development brought is not simply “building got cheap.” It is that buying remains the choice of bending your business to fit the tool, while building has returned as a realistic way to bend the tool to fit your business.

If a SaaS’s standard features cover you, buy it. But if there are places where you have been settling for “we’d really prefer it worked differently, but the SaaS doesn’t” — that premise deserves a fresh look. The break-even point is much closer than most people think.

For a specific assessment of which side the ledger favors in your case, I am happy to discuss within permissible limits in a consultation.