Build vs Buy: An AI Receptionist for Your Practice

Standing up a voice agent that books an appointment is a weekend now. Speech recognition is a commodity, a model holds a conversation, and one API call creates an appointment. A competent engineer reaches a working demo in two days, and the meeting goes well. The reason building is usually still the wrong call is not that prototype. It is everything that turns a prototype into something you would put in front of a patient at three in the morning.

We would enjoy building it, which is roughly the bias to correct for. So here is the honest version of the estimate.

2 days

to a working prototype on the happy path

4

failure paths the prototype does not contain

95+

integrations a bought platform already maintains

1

agreement that has to cover every party touching call content

The demo works on the first try. The agent says a time, the caller accepts, the appointment appears. Every product in this space clears that in a controlled room, and so will your prototype.

What the prototype does not contain is the roughly 1 in 5 calls where something is not as expected, and that fraction is the entire product. The happy path is identical everywhere. The failure path is the year of work nobody demonstrates.

The prototype also creates a confidence that is hard to walk back. It works in the room, in front of the people who approve budgets, and a working thing is far more persuasive than an engineer's caveat about the calls it has not seen. The estimate that follows is anchored to the two days, not to the year, and the distance between those two numbers is where most build decisions quietly go wrong.

What the prototype does not handle

The rejected write. The slot went during the conversation. What does the caller hear? Get it wrong and you tell a patient they hold an appointment that does not exist. This is a state machine, not a prompt, and it is set out in how write-back works.

The ambiguous patient match. Two records could be this caller. Guess and you split a clinical history in two, invisibly, for months. Calibrating that is its own project, described in patient matching.

The clinical turn. A booking call becomes a symptom description four sentences in. The system has to recognise it, stop, and hand over without forming a view. This is a safety requirement, not a feature, and getting the boundary wrong is the failure that matters most.

The outage. The practice system is unreachable. A naive build books into its own store and creates a reconciliation problem nobody owns, which is why we skip nightly syncs.

Each is straightforward to describe and none is quick to get right. Together they are why production systems in this category take a year, not a month.

The voice pipeline is not the easy part either

The weekend prototype leans on a stack you glued together: a voice layer, a model, a transcription service, a telephony provider. That glue is where the conversation breaks in production, and none of it shows in a quiet demo.

Turn-taking is the first wall. Silence is ambiguous, and a system that treats the end of speech as the end of a turn interrupts a caller who paused to think. Latency is the second: a reply that tests at 300 milliseconds spikes past 1 second under load, and a second of silence on a phone call reads as a dropped one. Then the transcript desynchronises under noise, and the agent answers the wrong sentence.

2care runs a native pipeline rather than a wrapper over those parts, which is the difference between owning that timing budget and inheriting four other companies' worst days. A build inherits them, and inherits them permanently, because the seams between four vendors are exactly where the hard failures live.

None of these is a research problem. They are solved, but solving them is a body of work with its own on-call rota, and it sits underneath the booking logic rather than beside it. A team that scopes the receptionist and forgets the pipeline has scoped perhaps a third of the build.

The integration tax

This is the cost most often underestimated, because it is not intellectually difficult and it never ends.

Each practice system is a separate contract, sandbox, authentication model and set of behaviours around appointment types and booking rules. They change without notice: a field that was optional becomes required, a rate limit tightens, an endpoint is deprecated with 90 days' warning. One integration is a project. 95+ integrations is a standing function with someone on call for it, which is what a bought platform carries and an internal build does not. An organisation building for itself needs one or two connectors, which is a fair point, and needs them maintained forever, which is the part left out of the estimate.

The tax is also uneven. The first integration teaches you the shape of the problem, and the tenth still surprises you, because each vendor's API encodes a different set of assumptions about how a practice runs. There is no economy of scale that makes the ninetieth connector free, only a team that has seen enough of them to move quickly.

The compliance chain

A system that transcribes calls, matches patients and stores outcomes is creating and maintaining protected health information.

Under HHS guidance that makes it a business associate, not a conduit, and the conduit exception does not apply. That means a business associate agreement covering every party in the chain, including the model provider behind the conversation.

A native platform has fewer parties to cover than a build glued from four vendors, each of which is its own agreement and its own procurement cycle running in series with legal review. For an internal build this is a legal exercise rather than an engineering one, and it is frequently what adds a quarter after the software works. What 2care signs and controls is set out on the compliance page.

Testing you also have to build

The part teams forget is that the agent has to be tested the way a clinical system is tested, not the way a web app is.

That means an adversarial simulation suite: interrupters, long-pause and elderly callers, background noise, packet loss, callers who change language mid-sentence. It means a regression gate, so that changing a prompt or a model cannot quietly push p95 latency or the escalation rate the wrong way without failing the build. 2care runs its own agents against exactly this harness before release, and it is the same harness 2care uses to keep the escalation boundary from drifting when a model changes underneath it. A build has to write that harness too, and without it every change ships on hope.

The harness is not optional insurance. On a system that books and escalates for patients, an untested change is a change you are shipping straight to a waiting room, and the regressions it introduces are found by callers rather than by a staging environment that never existed.

Build against buying, line by line

	Build	Buy
Time to a prototype	Days	Not applicable
Time to something safe for patients	Months to a year	Weeks of configuration
Integrations	You build and maintain each	Maintained for you
Failure paths	Discovered in production	Already encountered
Voice pipeline	Glue four vendors	Native, one budget
Compliance chain	Your procurement problem	Contractual
Own-agent testing	You build the harness	Built in
Ownership at two years	Needs a named owner	The vendor

The row that decides it for most organisations is the last. Internal tools lose their author, and a voice system answering patient calls without a maintainer is a liability, not an asset.

Where 2care is the wrong purchase

Three situations, and the first is more common than vendors admit.

A genuinely proprietary phone workflow that no product models. If the process is a differentiator and configuration cannot reach it, a product will frustrate you and building is correct.

A health system already running clinical software in production, with an engineering function, a compliance team and an on-call rota. The marginal cost of one more service is far lower than it looks from outside, and the control may be worth it.

A single integration to a system with an excellent API, with no prospect of a second. The integration tax argument mostly disappears, and so does much of the case for buying.

The question to settle before either path

Who owns this in two years.

An internal voice system answering patient calls without a maintainer is worse than either alternative, and it is the most common outcome of a successful build: the prototype gets built by someone enthusiastic, works, becomes load-bearing, and then that person changes role. If the organisation cannot name the team that will still be staffing it in twenty-four months, the decision has already been made, and the answer is buy.

Frequently asked questions

How long does a production-ready build actually take?

For a small team, 3 to 6 months rather than weeks, and the tail is failure paths and compliance rather than the conversation. The two-day prototype timeline predicts none of it, which is the single most common estimation error in this decision.

Can we build on a voice platform and skip the hard parts?

A platform gives you the conversation. The booking state machine, the patient matching, the escalation boundary, the eval harness and the compliance chain remain yours, and those are the parts that take the year rather than the weekend.

Does building avoid the BAA question?

No, it moves it. You still need agreements with every model, transcription and infrastructure provider touching call content, and a glued-together build has more of them to cover than a native platform does.

What is the maintenance load on 95+ integrations?

Continuous. Practice systems change, and the work is unglamorous and permanent. That is the honest argument for buying, and it is the one that ages best rather than worst as the systems underneath keep moving.

What if we build and it does not work out?

The common outcome is a system nobody owns still answering patient calls, which is worse than either alternative. Settle the ownership question before the build one, not after the enthusiastic engineer has moved on.

Answer four scenarios before you estimate

Before estimating a build, write down what happens when the slot is taken mid-call, when two patient records match, when the practice system is unreachable, and when the caller describes chest pain.

If your team can answer all four in detail, building is a reasonable option. If the answers are vague, that vagueness is the actual project, and it is considerably larger than the prototype that prompted the question.

See what is already maintained across the platform, or hear the failure paths handled on a live call when you book a demo.