Code Got Cheap. Your Process Didn't Notice.

We built an AI voice agent that calls patients, holds a real conversation, handles them going off script, and writes structured data back into the record.

It costs thirty to seventy-five cents a call. The vendor platforms we benchmarked against charge three to seven dollars.

What got our attention was the build. It cost us somewhere around twenty thousand dollars. Two years ago that was a procurement cycle, not a project.

We've spent 20+ years in healthcare software, and that shift is the biggest change we've seen in what this industry is capable of. Almost nobody has changed how they work because of it.

The two expensive failures

The most expensive failure in software is spending a year building something nobody uses.

Healthcare has a second one that costs nearly as much. You spend the year deciding. Business case. Prioritization. Integration assessment. Nothing in front of a clinician, a member, or a patient.

Neither failure is stupid. Both are rational answers to one assumption: writing code is expensive.

When implementation is scarce, you protect it with process. Requirements. Estimates. Gates. Committees. Every methodology we run in healthcare, from waterfall to SAFe, is built on that assumption.

The assumption is dead. Most of our process hasn't noticed.

Your delivery model sets your economics

This is where we see teams get it wrong, and we'll be honest that we were slow here ourselves.

You hand coding assistants to a team that still works through specs, tickets, and stage gates. You've just accelerated the cheapest step in the process. Every bottleneck is exactly where it was.

That's modern prices for 2015 delivery speed.

The economics only show up when you rebuild the loop itself. Code is the abundant thing now. Judgment and fast decisions are what stayed scarce. Until you do that rebuild, none of what follows is available to you, because inside your current process code is still expensive.

The new unit of innovation

What does it cost to test one product idea?

The old answer: six to twelve months of roadmap, if the idea survives prioritization at all.

Ours: a small senior team, about ten weeks, at a cost you cap before we start.

What you get is a working product in front of real users, built at production quality from the first week. Not a plan, not a prototype. Every change human-reviewed and traceable. Synthetic data while compliance sign-off runs in parallel. Real data the day it lands.

Where does the rest of the year go?

Ten weeks sounds like a sales number until you look at where the other months actually went. Writing code was never most of the calendar.

The months went to the apparatus around the code.

1/ Requirements and design, before the first line.

2/ Decisions queued behind sprint boundaries and steering meetings.

3/ Intent translated across handoffs, then rebuilt when the mismatch surfaces later.

4/ Integration, hardening, and UAT at the end.

None of that was waste. When building is expensive, getting it right on paper first is responsible.

Agile never escaped that logic either. "Working software over comprehensive documentation" is a twenty-five-year-old promise. But working software stayed too expensive to iterate in, so teams iterate on descriptions of it instead. Stories, acceptance criteria, backlogs.

That's the thing that changes. When a production-quality implementation is cheaper than the documents describing it, the working product becomes what you iterate on.

Then every artifact and ceremony faces one question:

Does this exist because building used to be expensive?

Whatever fails that test gets removed, not accelerated.

Run your own gates through it. The security review stays, because exposure is dangerous even when code is cheap. Every gate your regulator or your CISO owns stays. The six-week requirements cycle goes.

What's left is a short loop.

Planning is a working session measured in hours. Align on the skeleton, leave the details cheap to change.

Requirement, spec, design, build, and review collapse into one pull request. It states what was built, shows it working, and is the thing being decided on.

Agents write the implementation, the tests, and the documentation. A small senior team writes intent and verifies behavior. Nothing is left over for ceremonies to synchronize.

A capability described in the morning is often demoed that afternoon. A wrong guess costs a closed pull request instead of a re-specification cycle.

And because the product has run at production quality since day one, launch is a promotion instead of a phase.

Old methodologies optimize engineering hours. This one optimizes decisions per quarter. When code is cheap, deciding is the bottleneck.

Ten weeks is what's left when planning takes hours instead of a quarter and requirement-through-review is one artifact instead of five. It isn't the old process compressed. Remove less and you get twelve weeks. Remove nothing and you get a year.

Four things change when that's your unit of innovation

1/ Failure gets cheap.

You find out in weeks, with real users, before the big spend. A rejected bet still pays. You get a validated decision and evidence of what the product should have been. A year of roadmap debate returns neither.

2/ Ambition gets rational.

With the downside capped and small, ideas that always died at the business-case gate become fundable.

You have them. The member-facing tool. The clinician workflow everyone wants. The one that's been "next year" on the roadmap for two years because the build was too expensive to justify.

That constraint just disappeared.

3/ Portfolio math takes over.

The spend that used to buy one big bet now buys five to ten concurrent attempts. A small team for ten weeks against a program team for a year.

You stop picking one initiative annually and praying. You run a book of capped-downside bets, kill the losers in weeks, and scale the winners.

The losers leave nothing behind, and no maintenance tail is the underrated half of cheap failure. The winners were production-quality and human-reviewed from week one, so scaling one is a staffing decision rather than a rewrite.

No healthcare organization could afford this before. At a year per attempt, you can't run a portfolio at all. At ten weeks you can, and it's the obvious way to play it.

4/ Speed compounds.

Ten-week cycles buy four or five rounds of real market learning a year instead of one, and the lessons compound.

That's an argument for starting now, not at the next planning cycle.

"But we're regulated"

This model removes process ceremony. It never removes regulatory obligation.

Everything a regulator requires still ships with the product. Your compliance function keeps every gate it owns today.

What changes is the evidence. A human-reviewed, timestamped record of every change. Executable checks of required behavior. Your auditors can replay that record instead of reading documents that drift out of date the week they're approved.

What we're not saying

Documentation still has a place. Humans don't leave the loop. And we're not telling you to rebuild the systems running your claims or your EHR this way. Leave the systems of record alone and build around them, which is where nearly all new healthcare software lives anyway.

The claim is narrower than that. For building new things, the smallest process now gets you the most.

The gate is methodological, not technological. Everyone already has the tools, which is exactly why the tools confer no advantage. So: does your delivery model still treat code as the expensive thing? And is anyone at your company permitted to work as if it weren't?

The question

One question for your next leadership meeting, and it isn't about your AI tooling strategy.

Which bet would we place this quarter if a failed one cost ten weeks instead of a year?

Most executives we ask can name theirs immediately. It's the one that's been "next year" for two years.