The telehealth tech stack in 2026: what you build vs. what you rent
Every DTC care program converges on the same eight layers. The winners differ in where they spend engineering time — and the pattern is consistent: build what differentiates (funnel, experience, data), rent what is regulated (clinical, pharmacy, identity).
The stack: (1) storefront and funnel — build, it is your conversion rate; (2) intake — build the surface, rent the clinical logic and state rules; (3) clinical layer (medical group, clinician queue, protocols, eRx) — rent, it is a regulated operation, not software; (4) pharmacy and fulfillment — rent via a routed bench; (5) labs — rent networks, build the loop into your product; (6) payments and subscriptions — rent processors, build the billing logic; (7) messaging and support — rent tools, build the clinical/non-clinical triage line; (8) data and analytics — build first-party, keep third-party out of the clinical zone. Engineering time concentrates in the storefront, the status/patient surface, and the event plumbing between layers — which is why an event-driven API with webhooks beats stitching six vendors yourself.
The eight layers
| Layer | Verdict | Why |
|---|---|---|
| Storefront & funnel | Build | Your conversion rate is your company; never rent it. See white-label models |
| Intake surface | Build on rented logic | The UX is funnel; the branching, state rules, and consent versions are regulatory code you should not maintain |
| Clinical layer | Rent | Medical group, licensure, protocols, review queue, eRx/EPCS — an operation with software attached, not software |
| Pharmacy & fulfillment | Rent (routed bench) | Licensure matrix + routing beats any single-pharmacy integration; see pharmacy licensing |
| Labs | Rent networks, build the loop | Ordering/results are commodity; the completion-chasing loop is product; see labs |
| Payments & subscriptions | Rent processing, build logic | Your merchant account, your descriptors, your dose-step billing rules; see chargebacks |
| Messaging & support | Rent tools, build triage | The clinical/non-clinical line is yours to enforce; see patient support |
| Data & analytics | Build first-party | Third-party stays out of the clinical zone; see pixels and HIPAA |
Where the engineering time really goes
Teams budget for the funnel and underestimate the plumbing: keeping the patient surface truthful about state that lives in other systems. “Your prescription was approved, your box ships Tuesday, your check-in is due Friday” requires encounter, pharmacy, shipping, and billing events in one stream. Stitch six vendors and you build that event bus yourself, forever; consume an event-driven clinical API and the stream is the product. This is the quiet argument that decides most build-vs-rent debates in practice — not any single layer, but the integrals between them.
Three reference stacks
- No engineers: a done-for-you operator’s hosted storefront. Fastest start, lowest ceiling; plan the exit. See the platform comparison.
- Small product team (most brands): your Next.js storefront and patient surface; clinical, pharmacy, and labs behind one API with webhooks; Stripe under your own account; support tool wired to the event stream.
- Platform team (scale or payer motion): the same, plus an EHR bridge for insurance lines, a data warehouse on the first-party stream, and agent tooling on the support queue. See EHR vs. infrastructure.
Eight questions for any vendor in the stack
- Can we export everything? Records, events, patients — via API, in the contract, demonstrated on a real patient. See switching infrastructure.
- What do webhooks actually cover? Ask for the event catalog. A “webhook-supported” platform with four events cannot keep your patient surface truthful.
- Which states, today? Clinician licensure and pharmacy coverage as a current matrix, not a “nationwide” adjective.
- Whose merchant account? If revenue settles into the vendor’s processor, your revenue has a landlord. See the pricing models.
- Where is the BAA and what does it cover? Every vendor that touches PHI signs one; the gaps are where their breaches become your breaches.
- What happens when a state rule changes? Who watches, how fast changes ship, and what changed last quarter — the answer tells you whether compliance is a team or a PDF.
- Can an agent drive it? If the roadmap includes AI on support or operations, the API must be complete enough for an agent to use — the same test your own engineers would apply.
- Who else at our size? References at your volume, not the logo wall.
Frequently asked questions
What software do you need to start a telehealth company?
A storefront and checkout, an intake flow, a clinical back office (medical group, clinician review, e-prescribing), pharmacy fulfillment, optionally labs, subscription billing, support tooling, and analytics. The strategic question is which of these you assemble from parts versus consume as integrated infrastructure — not which single app to buy.
Should we build our own intake and EHR?
Build the intake experience — it is part of your funnel — but rent the clinical logic behind it (protocol branching, state modality rules, consent versions) unless you want to maintain regulatory code forever. A traditional EHR is usually the wrong shape for DTC; see our EHR vs. infrastructure guide.
How many engineers does a telehealth brand need?
On integrated infrastructure: a small product team — front-end, funnel, and integrations — ships a launch in weeks; see our launch timeline. Assembling the stack from separate clinical, pharmacy, lab, and billing vendors typically consumes a platform team for quarters before the first patient.
What actually differentiates a telehealth brand technically?
Conversion and retention surfaces: the funnel, onboarding, status experience ("where is my box, what happens next"), check-in UX, and first-party data. Nobody chooses a brand for its clinician queue software — they leave brands whose patient experience is a hosted portal.
From first call to first patient, in weeks.
A 15-minute intro call, sandbox credentials the same day, go-live in 3–4 weeks — new launches and existing patient bases alike.