Build or Buy Your Telehealth Stack? An Honest Breakdown

Every telehealth company faces this early, usually with a whiteboard and a spreadsheet that makes buying look obviously correct.

Buying often is correct. But the spreadsheet usually compares the wrong things, and the companies that regret their choice tend to regret it eighteen months later rather than in month two.

We build custom telehealth software, so read the recommendation with that in mind. We also talk clients out of it fairly often, and this is roughly the conversation.

What "buy" actually gets you

All-in-one platforms handle scheduling, video, charting, e-prescribing, messaging, and billing, usually with a BAA and some compliance posture out of the box.

The genuine advantages:

Speed. Weeks to first patient, not months. For a company still proving demand exists, that is worth a great deal.

Compliance groundwork done. BAA-covered infrastructure, audit logging, access controls. You still own your policies, training, and risk assessment — nobody sells you compliance — but the technical foundation is there.

Someone else maintains it. Integrations, uptime, updates, security patches.

Predictable cost early. A per-provider or per-visit fee is easy to budget.

What buying costs you later

The patient experience is theirs. This is the big one. Your intake looks like their intake. The flows work how they work. When your conversion problem is on step four of their questionnaire, you file a feature request and wait.

For a company whose whole differentiation is a better patient experience, that's a structural problem, not an inconvenience.

Pricing scales against you. Per-provider or per-visit pricing that's trivial at 200 visits a month becomes a serious line item at 20,000. Model it at your projected volume, not your current one.

Their roadmap becomes yours. Something you need is 18 months out or never. There's no escalation that changes that.

Data portability. Getting your clinical data out later is harder than getting it in. Ask about export formats before you sign, not after.

What building actually costs

Founders consistently underestimate this, and it's not the interesting parts that consume the time.

The unglamorous foundation — auth, roles, permissions, audit logging, admin tooling, notifications — is typically a third or more of the build and demos terribly.

Compliance work is real engineering. BAA-covered infrastructure, encryption, access review, logging that satisfies an auditor. It costs more and moves slower than a standard build.

Integrations are where estimates break. E-prescribing, labs, pharmacy, payments. Each has its own approval process, and some of those processes are measured in months regardless of how fast you code.

It never finishes. You now own maintenance, security patching, uptime, and the on-call rotation, permanently.

A realistic first build is months, not weeks, and it needs someone technical accountable for it who isn't also doing three other jobs.

The middle path most companies should take

Build or buy is a false binary, and the answer that works for most companies is neither extreme.

Buy the clinical infrastructure. Build the patient experience.

Concretely: use a platform with a decent API for charting, e-prescribing, and the clinical record. Build your own marketing site, intake flow, patient portal, and subscription billing on top of it.

You get the compliance-heavy, integration-heavy, genuinely-hard-to-replicate parts from someone who specialises in them. You own the surfaces that determine whether patients convert and stay — which are the surfaces that actually differentiate you.

This is what most of the telehealth companies we work with end up doing, and it's usually what we recommend before anyone asks us to build everything.

How to decide

Buy the whole thing if: you're pre-product-market-fit, your care model is fairly standard, speed matters more than differentiation right now, and you have no technical leadership in-house. Get to first patient, learn, revisit in a year.

Build the patient layer if: your intake or patient experience is your actual differentiator, your conversion depends on flows the platform won't change, or platform fees are becoming a real cost at your volume.

Build the whole thing if: your clinical model is genuinely unusual and no platform fits, you're at volume where fees exceed engineering cost, or the software is the product you're selling. This is a smaller set of companies than think they're in it.

Questions to ask any platform before signing

1. What's the pricing at 10x our current volume?
2. What API access do we get, and what's rate-limited?
3. Can we control the patient-facing UI, or only configure it?
4. What does data export look like if we leave — format, completeness, timeline?
5. Will you sign a BAA, and what does it actually cover?
6. What's your uptime history, and what's the SLA?
7. Which integrations are included versus extra?

Question 4 is the one people skip and later wish they hadn't.

The mistake that costs the most

Not the choice itself. It's building a data model that assumes the choice is permanent.

If everything about your patient, subscription, and encounter data lives inside the platform's schema, migrating later means an extraction project under live patients. If you keep your own record of patients, subscriptions, and encounters — with the platform as a system you integrate with rather than the sole source of truth — then changing your mind later is a project rather than a crisis.

Own your patient and billing data from day one, whatever else you decide. That single choice preserves every other option.

---

We build the patient-facing layer on top of clinical platforms, and the full stack when it's genuinely warranted. See the telehealth build.