How I replaced a $60,000/month Twilio bill with a $400 custom solution

The bill was running $2,500–$3,000 on a busy day, and almost all of it was inbound calls sitting in a Twilio IVR. Nobody was buying software — they were renting a phone menu by the second.

The invoice was running about $60,000 a month. On a heavy day it was $2,500 to $3,000.

Nobody had opened it in over a year. That's the normal case, not the embarrassing exception — a usage-based vendor invoice is the easiest line item in a business to stop reading, because it arrives already paid.

When I did open it, almost the entire bill traced to one thing: inbound calls landing in a Twilio IVR.

The bill was a phone menu, charged by the second

This is the part that surprises people. They assumed they were paying for a platform. They were paying for hold time.

Every inbound call hit the Twilio IVR and then stayed there — through the greeting, through the menu, through the pause while the caller decided, through the re-prompt when they picked wrong, through the transfer. Twilio meters inbound minutes, and it meters the programmable voice layer running the menu. High call volume plus a menu people had to sit through equals a bill that scales with your customers being confused, not with your business getting bigger.

That's a terrible thing to have as a variable cost. The busier you get, and the longer callers hesitate, the more you pay.

Read the invoice before you write a line of code

I exported eighteen months of usage and grouped it by product line before touching anything. Three things fell out:

The overwhelming majority of spend was inbound voice and the programmable IVR on one call path.
A meaningful slice was phone-number inventory nobody had audited — numbers provisioned for things that ended years earlier, quietly billing every month.
The remainder was genuinely small.

That ratio is the whole story. They weren't paying for Twilio's platform. They were paying Twilio's per-second margin on a menu that could run anywhere.

The number-inventory audit alone — deleting numbers nobody used — was real money before a single line of code was written. That's the cheapest work in this entire project and it's available to you today.

The rule I use before replacing any usage-based vendor

I don't replace a vendor because it's expensive. I replace it when all three are true:

You use a narrow slice. If you touch 10% of the product, you're subsidizing the 90% you don't.
That slice is a commodity underneath. Voice termination bottoms out at carriers with published rates. There's no moat in the middle of a phone menu.
The switching risk is bounded. You can run both in parallel and cut over gradually.

Fail any one and you should stay. Plenty of companies rip out a vendor to save $2,000 a month and take on an operational burden that costs them ten times that in incidents.

This one passed all three, which is exactly why it was worth doing.

What actually got built

A small service. Not a platform.

It answered inbound calls and ran the menu logic directly, on infrastructure priced by the month rather than by the second
It handled routing and transfer to the same destinations as before
It kept a queue with retry and backoff, because telephony fails in ways APIs don't
It exposed the same internal interface the application already called

That last point matters more than the rest. The application code barely changed — I swapped the implementation behind an interface that already existed, which meant rollback was a config flag rather than a deploy.

Total: about $400 a month. Fixed, not metered. The cost stopped moving when call volume moved.

The cutover that keeps you employed

Never flip a live phone path in one go. Customers notice immediately and they notice loudly.

Shadow mode. New service receives the call events, handles nothing live, logs what it would have done. Run a week. Diff against Twilio's own records.
1% live. A real slice of real calls, watched closely.
Ramp on answer rate and completion, not on confidence. If callers fail to reach the right destination more often than the incumbent, you stop. The baseline from step one is the whole point.
Keep the old path warm for 60 days. The flag stays. It costs nothing and it's the difference between an incident and a shrug.

Where AI actually helped

Not in the way people expect. It didn't design the architecture. It compressed the tedious parts:

Parsing eighteen months of messy usage exports into something groupable
Writing the first pass of the call-handling service, including the retry semantics
Generating the diffing harness for shadow mode

That's the honest shape of AI-assisted work on infrastructure: it collapses the boring 70%, and you spend the time you saved on the 30% that will page you at 2am.

What to check on your own invoices this week

Pull twelve months for every usage-based vendor and ask three questions:

What single line is most of the spend? Not most of the line items — most of the dollars.
Is that line a commodity with published wholesale pricing underneath?
Are you paying for provisioned inventory you no longer use? Phone numbers, seats, environments, endpoints.

If the biggest line is metered by the second and the underlying thing is a commodity, you're not buying software. You're renting a meter.

The takeaway: a big vendor bill is rarely a pricing problem. It's a usage problem nobody has looked at. Read the invoice first — sometimes the audit alone pays for the project, and sometimes the build turns out to be unnecessary.