A few years ago, telehealth was the "nice to have" tab on a clinic's website. Today it's the front door. Patients book a video call before they book a clinic visit, and a growing number never set foot in a physical waiting room at all.

But behind the smooth patient experience, building an actual online telehealth service is messier than most "we built it in a weekend" threads make it sound. I've been deep in this space for a while now, and wanted to share what actually matters when you're building one — beyond the surface-level pitch.

What "telehealth" really covers

The word gets used loosely. In practice, online telehealth services fall into four buckets:

Synchronous video visits — live doctor-patient calls, the most visible part.
Asynchronous care — patients send symptoms, photos, or messages; a clinician replies within hours.
Remote patient monitoring (RPM) — connected devices streaming data to a clinician dashboard.
Store-and-forward — images, scans, or reports sent to a specialist for review.

Most platforms claim to do all four. Very few do any of them well.

The parts users see — and the parts that decide if it ships

Patients judge a telehealth product on three things: how fast they can talk to a doctor, how clear the video is, and whether the prescription shows up at their pharmacy without a phone call. That's the whole UX evaluation.

What decides whether the product is actually shippable sits underneath:

HIPAA-grade infrastructure — encrypted video, encrypted database, audit logs on every PHI access, BAAs with every vendor that touches data.
EHR/EMR interoperability **— if you can't read or write to the systems clinicians already use, you're a silo. Silos don't get adopted.
**State-by-state licensure logic — a doctor in Texas can't see a patient in California unless they're licensed there. Your booking flow has to know this.
Prescription routing — ePrescribing through Surescripts, with controlled-substance handling that meets EPCS requirements.
Payment + insurance — cash-pay is simple. Insurance is a multi-month integration project.

The ratio of "stuff users see" to "stuff that decides if the platform survives" is roughly 1 to 10.

Where most telehealth builds quietly fail

The same patterns keep showing up across teams I've worked with:

1. Treating compliance as a launch-day task. Teams build the product, then ask "how do we make it HIPAA compliant?" two weeks before launch. Backwards. Every architectural decision (where data lives, how it's logged, who can read it) has to bake in compliance from day one. Retrofitting it costs three times more.
2. Skipping the audit log. Every view, every edit, every export of patient data needs a who-did-what-when record retained for six years. Most early-stage telehealth apps log almost nothing, then panic when their first enterprise customer asks for SOC 2.
3. Underestimating clinician workflow. The patient side is easy to design. The clinician side — charting, signing, refilling, billing, handing off — is where adoption lives or dies. A doctor who has to click 14 times to close a visit will quietly stop using your platform.
4. Building video before figuring out async. Live video is the flashy demo. But asynchronous messaging handles 60–70% of primary-care visits more efficiently. Teams that prioritize async first usually have better unit economics.

A practical tech stack that works in 2026

No single right answer, but the patterns that consistently ship without exploding:

Video — Twilio Video, Daily.co, or Amazon Chime SDK. All offer HIPAA-eligible plans under BAA.
Backend — Python (Django or FastAPI) or Node, with PostgreSQL for structured data and KMS-managed encryption for PHI.
Hosting — AWS or GCP with a signed BAA. Pin your regions and lock down workloads with org policies.
EHR integration — FHIR APIs where available, HL7 where you have no choice. Redox if you want a translation layer.
ePrescribing — DoseSpot or Surescripts.
Identity verification — Stripe Identity or Persona for signups; ID.me for federal workflows.

A quick code example: audit-logging a PHI access event

Here's the kind of pattern that keeps you out of trouble. Every read of patient data should log who, what, when, and from where — and the log itself should be append-only, retained for six years.

Two things to notice: the log writes happen in a dependency, not inside the business logic (so they can't be skipped), and the table should have insert-only permissions for the app role — no updates, no deletes. That's what makes the log defensible if OCR ever asks.

What 2026 actually looks like for telehealth

Three shifts worth watching this year:

AI scribes are now standard, not novel. Patients expect a written summary at the end of every visit, generated automatically. The clinical-quality bar is rising fast.
Cross-border telehealth is starting to work in narrow corridors — India-to-US diaspora consultations, EU-to-EU specialist networks — but regulation is still the bottleneck.
Asynchronous-first models are taking real market share from "every visit is a video call" platforms. Patients prefer it for routine care. Clinicians can see 3x more patients per hour.

If you're building one

Start with the boring stuff. A telehealth platform with mediocre video but bulletproof compliance, clean audit logs, and a clinician workflow that doesn't make doctors hate their day will outlast ten beautifully designed MVPs that skipped those layers.

The companies winning in this space aren't the ones with the slickest patient app. They're the ones who took compliance, interoperability, and clinician UX seriously from week one.

Build for the parts users don't see. The parts they do see will work themselves out.

If you're building in this space and want the HIPAA, EHR, and audit-log scaffolding handled out of the box, I work on VertiComply — we generate production-ready healthcare app code with 15+ compliance frameworks built in. Happy to chat with anyone going down this path.