Build vs Buy vs Hybrid for Telemedicine

This is engineering guidance, not legal advice. Confirm specifics with qualified counsel.

Why this matters

Almost every telemedicine project that runs out of money does so because the team answered the build-vs-buy question by accident instead of on purpose. They either bought a closed platform and discovered in month four that it cannot do the one clinical thing their product is for, or they decided to "just build it" and spent a year and a small fortune rebuilding a video stack that they could have rented for the price of a junior engineer. This article is for the founder, product manager, or health-system lead who has a telemedicine idea and a budget, and who needs to decide — before any code is written — how much of the platform to own. Getting this decision right is the difference between launching in weeks on a sound footing and rebuilding the product after you learn what telemedicine actually demanded. Because this is healthcare, one axis of the decision is non-negotiable: every option leaves a different amount of compliance responsibility on your shoulders, and you must know which before you sign anything.

The decision is a spectrum, not a switch

People talk about "build versus buy" as if there were two doors. In telemedicine there are at least four, and they sit on a line. At one end you own nothing but a login; at the other you own every line of code and every server. Naming the four points clearly is the whole battle, because most bad decisions come from confusing two of them.

The first point is the turnkey platform. You buy a finished telehealth product — provider app, patient app, scheduling, video, sometimes billing — configure it, put your logo where the vendor allows, and go live. You are a tenant. The second point is the white-label platform: the same idea, but the vendor lets you brand it as your own and exposes more configuration, sometimes an API to bolt things onto the edges. You are a tenant with a nicer apartment and permission to repaint.

The third point is the hybrid build, and it is where most successful custom telemedicine products actually live. You build your own product — your clinical workflow, your patient and provider apps, your data model — but you do not build the genuinely hard infrastructure underneath. The most important piece you rent is the real-time video layer, bought from a Communications-Platform-as-a-Service (CPaaS) vendor: a company that sells video, voice, and messaging as an API you call, so you never run a media server yourself. You own the product; you rent the plumbing. The fourth point is the fully custom build: you build the product and the plumbing, including running your own video infrastructure on open-source media servers. You own everything, and you owe everything.

Figure 1. The build-vs-buy spectrum. Moving right buys you control and differentiation; it also hands you more cost, more time, and more compliance to own.

Hold these four points in mind. The rest of this article is about which one fits your project, and the four things you trade as you move along the line.

The four things you are really trading

Every step to the right on that spectrum moves four sliders at once. Read them together; no single one decides the question.

The first is money — but not in the way most comparisons present it. A turnkey platform looks cheap because the upfront number is small and the cost is a monthly subscription. A custom build looks expensive because the upfront number is large. The honest comparison is total cost over time, which we work through below, because a subscription that never ends and a build that you own behave very differently across three years.

The second is time to launch. Buying a finished platform can put a branded service in front of patients in weeks. A hybrid build, where you assemble your product on a rented video layer, is typically a matter of months. A fully custom build, where you also stand up your own video infrastructure, is the slowest path — commonly six to twelve months before a first usable version, and the difference is almost entirely the infrastructure you chose to build instead of rent.

The third is control, which is really the ability to do the clinical thing your product exists for. A turnkey platform does what its vendor decided telemedicine is. If your product's reason to exist is a specific intake flow, an unusual multi-party consult, a device integration, or an AI feature wired into the visit, a closed platform will eventually tell you "no", and that "no" arrives after you have already committed. Control is the axis you are buying when you move right.

The fourth is compliance ownership, and it is the one founders systematically underprice. It deserves its own section, because in healthcare it is not a footnote — it is half the decision.

Compliance ownership is the hidden axis

Every telemedicine product in the United States sits on the same legal floor: the Health Insurance Portability and Accountability Act (HIPAA), the federal law that governs protected health information (PHI) — any health data tied to an identifiable person. The full picture of what HIPAA asks of a product team is in the HIPAA guide for product teams. For the build-vs-buy decision, the question is narrower and sharper: when patient data flows through a vendor's system, who is legally responsible for protecting it?

The mechanism that answers this is a contract called a Business Associate Agreement (BAA) — the signed promise a vendor makes, before it is allowed to touch PHI on your behalf, to protect that data to HIPAA's standard and to tell you if it leaks. HIPAA requires this contract whenever a "business associate" handles PHI for you (45 CFR §164.502(e)); the details of what a good one contains are in the BAA guide. The rule of thumb that saves projects: a vendor either has a signed BAA covering your use, or it does not. There is no "probably fine". Encryption does not substitute for it — a tool can be fully encrypted and still be a HIPAA violation if no BAA is in place. "Encrypted" and "compliant" are two different words.

Here is how the BAA question maps onto the spectrum. When you buy a turnkey or white-label platform, the vendor runs the whole stack and signs one BAA that covers it. You still have your own HIPAA duties — you are the covered entity or its business associate — but the platform's internal pieces are the vendor's responsibility to wrap in their own downstream contracts. The compliance surface you personally own is small.

When you build hybrid, the responsibility splits. The CPaaS video vendor signs a BAA covering the video layer — and the major clinical-grade CPaaS vendors do offer one (more on that below). But everything else in your product — your database, your file storage, your logs, your analytics, your error-tracking tool, your email and SMS senders — is yours to make compliant, and every third-party piece that can see PHI needs its own BAA. The pattern for wrapping all of this into a defensible whole is the subject of the compliance architecture pattern. The compliance surface you own is medium, and it is real work.

When you build fully custom, you own all of it, including the video infrastructure. There is no upstream vendor BAA to lean on for the media path, because you are running the media servers. Every safeguard HIPAA's Security Rule names — access controls, audit logging, encryption, a contingency plan (45 CFR §164.308 and §164.312) — is yours to design, implement, document, and defend in an audit. The compliance surface you own is the entire thing.

Figure 2. Compliance ownership across the spectrum. Buying shrinks the surface you personally own; building grows it. The BAA boundary moves with the decision.

One more compliance note that sits underneath all four options and is changing as we write. HIPAA's Security Rule — the part that dictates the technical safeguards — is in the middle of its first major update in over twenty years. As of June 2026 the update is a Notice of Proposed Rulemaking (NPRM, RIN 0945-AA22, published January 6, 2025); it is proposed, not final, and proposes to make several controls that are today "addressable" into hard requirements, including multi-factor authentication and encryption. Whichever way you decide build-vs-buy, plan for that floor to rise. If you buy, ask the vendor how they will meet it; if you build, budget for it now rather than retrofitting later.

The cost math, worked out loud

The reason "buy is cheaper" and "build is cheaper" are both repeated endlessly is that they are answers to different questions over different time windows. Let us make the arithmetic explicit, in round planning numbers rather than a quote, because the shape is what matters and your own figures will replace these.

Start with the buy path. A white-label or turnkey telehealth platform commonly costs something like $20,000 to $80,000 to set up and license, then $500 to $5,000 per month to run, depending on scale and features. Take a mid-case: $40,000 to start, then $3,000 per month. Over three years the subscription alone is $3,000 × 36 = $108,000. Add the setup and you are at roughly $148,000 across three years — with a working product from week one and the vendor carrying most of the platform's compliance and maintenance.

Now the fully custom path. A custom telemedicine build commonly lands somewhere between $150,000 and $500,000 or more, and takes six to twelve months before launch. Take a conservative mid-case of $250,000 to build. That number does not stop there: a live clinical product needs maintenance, security updates, infrastructure, and on-call support — budget another 15% to 25% of the build cost per year as a planning figure, so call it $50,000 a year. Three-year total: $250,000 + (3 × $50,000) = $400,000, and you do not see a patient until month nine.

On those mid-case numbers, buying is roughly $148,000 over three years and building is roughly $400,000 — buy looks like the obvious winner. And for many products it is. The catch is the third axis: control. The custom build's $400,000 buys a product that does exactly what your clinical vertical needs and that you can extend forever; the $148,000 subscription buys a product that does what the vendor decided, and the day it cannot do the thing your business depends on, the real cost is not the subscription — it is the rebuild.

The hybrid path is the one the arithmetic usually rewards, because it removes the most expensive line item from the custom build without giving up control. Standing up and operating your own real-time video infrastructure — media servers, global relay, scaling, the constant tuning that clinical-grade video needs — is one of the heaviest parts of a from-scratch build. Renting it from a CPaaS vendor turns that capital project into a usage bill. A clinical-grade video API with a BAA is priced per participant-minute or per active host; one well-known option, for example, signs its HIPAA BAA from a tier that starts around $500 per month, and usage scales from there. So a hybrid build might cost, say, $150,000 to develop your product on top of a rented video layer, plus the video subscription and your own maintenance — landing meaningfully below the fully-custom $400,000 while keeping the clinical control that buying gives away. You buy the hard infrastructure and build the differentiating product.

Figure 3. A three-year cost shape, not a quote. Buying is cheapest and fastest; fully custom is most expensive and slowest; hybrid sits between, and is where control meets affordability for most clinical products.

The detailed, line-by-line version of this model — feature-to-effort, compliance multipliers, integration multipliers — lives in the telemedicine cost model, and the practice of turning an idea into a defensible number is the subject of scoping and estimating a telemedicine project.

The video layer is the decision inside the decision

For most teams, the single biggest lever on this whole question is one component: the real-time video. It is the most specialized, most expensive piece to build well, and the one with the clearest rental market. So the hybrid path's whole premise — buy the hard part, build the product — turns on choosing whether to rent or own the video layer specifically.

You rent it from a CPaaS vendor: you call an API, they run the media servers that route the call. The clinical-grade vendors that matter here all offer a HIPAA BAA, which is the price of admission for telemedicine. To name the landscape without ranking it: Twilio offers a BAA on its HIPAA-eligible products, Vonage signs one for its Video API when the HIPAA feature is enabled, Daily provides a HIPAA package with a signed BAA, Amazon Chime SDK is covered under the AWS BAA, Agora supports HIPAA, and LiveKit Cloud signs a BAA from its Scale tier. The "build" alternative for the video layer is to self-host an open-source media server — mediasoup, Janus, or LiveKit's open-source server among them — which gives you total control and no per-minute bill, but hands you the operations and the entire compliance burden for the media path. The full comparison, with the BAA column that telemedicine forces, is the subject of building vs buying the video layer, and the engineering trade-offs of specific self-hosted servers are covered in the Video Streaming section's SFU comparison.

The practical guidance: unless real-time media is your product — you are building a video infrastructure company — rent the video layer and spend your build budget on the clinical product around it. Self-hosting the media stack is worth it at large, predictable scale where the per-minute bill would dwarf an operations team, or where a regulatory or contractual requirement forces the media onto infrastructure you control. For most telemedicine products neither is true on day one.

The comparison at a glance

The table places the four options against the axes that decide the question. The ratings are deliberately coarse, because the goal is to see which option is in which weight class, not to score it to a false precision.

Read it as a single shape: cost and time and compliance all climb together as control climbs. There is no free lunch on this table; there is only the question of which trade fits the product you are actually building.

Three common mistakes that cost the most

The first and most expensive mistake is mistaking a consumer tool for a compliant one. A team picks a familiar, polished consumer video app because "it's encrypted", wires it into a clinical flow, and only later learns that the consumer tier carries no BAA — so the entire service has been moving PHI through a vendor with no contract to protect it. Encrypted is not compliant. Before any tool touches patient data, the question is binary: is there a signed BAA covering this use? If not, it does not matter how good the product is.

The second mistake is assuming one BAA covers the whole stack on the hybrid path. Teams sign the CPaaS video vendor's BAA, breathe out, and forget that their database host, file storage, error-tracking tool, analytics, and SMS sender can all see PHI too. Each is a separate business associate that needs its own BAA, and a single un-covered tool — an analytics script that logs a patient identifier, an error tracker that captures a screen with a name on it — is a breach waiting to be discovered. The hybrid path's compliance surface is the sum of every vendor that can see PHI, not just the video one.

The third mistake is building the video layer when you did not need to. A capable engineering team, told to "build a telemedicine platform", reaches for an open-source media server and spends the first three months and a large share of the budget getting clinical-grade real-time video to work across firewalls, networks, and devices — a problem the CPaaS vendors have already solved and will rent you for a usage fee. Unless real-time media is your product, that is budget spent rebuilding plumbing instead of building the clinical product that differentiates you. Move right on the spectrum because you need control of the product, not because building infrastructure feels more like real engineering.

How to actually decide

Walk the decision as an ordered set of questions, because an early answer often ends it.

First: does a finished platform already do your clinical job? If your product is a fairly standard synchronous-visit service and an off-the-shelf platform covers your vertical's rules, buying is the fastest, cheapest sound choice — validate the market before you build anything custom. If the platform cannot do the one clinical thing your product exists for, buying is a trap, and you have your answer.

Second, if you are building: is real-time video your product, or a feature of it? If video infrastructure is the thing you are selling, you may need to own the media layer. For everyone else — the overwhelming majority — rent the video layer from a CPaaS vendor with a BAA and put your budget into the clinical product. This is the hybrid path, and it is the right default.

Third: what scale and what constraints are real on day one? Self-hosting the media stack earns its keep at large, predictable volume, or under a contract or jurisdiction that forces the media onto infrastructure you control. If neither is true yet, you can start hybrid and move the video layer in-house later if the bill ever justifies it — designing a clean seam between your product and the rented layer keeps that option open.

Fourth, underneath all of it: what compliance can you carry today? Every step right adds HIPAA surface you must own. Be honest about the counsel, the security help, and the engineering you have now. It is better to buy or go hybrid and own a small, well-run compliance surface than to build custom and own a large one you cannot staff.

Figure 4. Four questions, in order. An early no ends the decision — most clinical products that need any custom work land on the hybrid path.

Where Fora Soft fits in

Fora Soft has built real-time video software since 2005 — video conferencing, streaming, surveillance, e-learning, and telemedicine — so the build-vs-buy line is one we help teams place on purpose rather than by accident. The compliance-first version of our advice is consistent: rent the hard infrastructure where a vendor will sign a BAA and carry the operational load, and spend the build budget on the clinical product and the integrations that actually differentiate you. We work most often on the hybrid path — a custom clinical product on a BAA-covered video layer, wrapped in a defensible HIPAA architecture — because for most telemedicine teams that is where control meets affordability. Where a full custom build is genuinely warranted, the requirement that drives it should be named and real, not a reflex. Our telemedicine software development team builds the clinical product on whichever video layer fits, and when the video itself has to be owned, our HIPAA-ready telehealth video platform work covers WebRTC, EHR integration over FHIR and AI scribes.

The handbook

Fora Soft Video Engineering Handbook

We wrote the seven volumes that cover the whole video stack, pixel to production: compression, delivery, sound and AI, across 9,000+ pages. Wherever you land on this spectrum the same machinery runs underneath, so start with the delivery volume on WebRTC, players, DRM and the economics of streaming — that is the layer this decision either rents or owns. The compression volume explains what the media is before anyone routes it, and the real-time AI volume prices serving per stream-hour and walks the regulatory ground a clinical product stands on. Read the series and you can specify, price and build the platform this article is about. Written by Nikolay Sapunov, CEO at Fora Soft.

Browse the handbook on Amazon →7 volumes · Kindle & paperback

See our case studies

References

1. HIPAA Privacy and Security Rules — 45 CFR Part 164 (incl. §164.502(e) business-associate contracts; §164.308 administrative safeguards / contingency plan; §164.312 technical safeguards — access control, audit, encryption). Electronic Code of Federal Regulations. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164 — Tier 1. Accessed 2026-06-15.
2. HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information (NPRM, RIN 0945-AA22), 90 FR 898, published January 6, 2025. U.S. Department of Health and Human Services / Federal Register. https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information — Tier 1. Proposed, not final as of 2026-06-15. Accessed 2026-06-15.
3. HIPAA Security Rule NPRM — overview and fact sheet. HHS Office for Civil Rights. https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/index.html — Tier 1 (agency guidance). Accessed 2026-06-15.
4. Software as a Medical Device (SaMD) / Clinical Decision Support guidance — the display-vs-interpret line for any clinical feature you build or buy. U.S. Food and Drug Administration. https://www.fda.gov/medical-devices/digital-health-center-excellence/software-medical-device-samd — Tier 1. Accessed 2026-06-15.
5. Twilio and HIPAA — HIPAA-eligible products and Business Associate Addendum. Twilio. https://www.twilio.com/en-us/hipaa — Tier 4 (first-party vendor). Accessed 2026-06-15.
6. Business Associate Agreement for Services / HIPAA compliance with video. Vonage. https://www.vonage.com/legal/communications-apis/baa/ — Tier 4 (first-party vendor). Accessed 2026-06-15.
7. HIPAA compliance details for the Daily.co video call API. Daily. https://www.daily.co/blog/hipaa-compliance-details-for-the-daily-co-video-call-api/ — Tier 4 (first-party vendor). Accessed 2026-06-15.
8. LiveKit pricing and HIPAA BAA (Scale tier). LiveKit. https://livekit.io/pricing — Tier 4 (first-party vendor). Accessed 2026-06-15.
9. Telemedicine Platform Development Costs: The Complete 2026 Guide. Fora Soft. https://www.forasoft.com/blog/article/telemedicine-platform-cost — Tier 6 (educational orientation; the section's own commercial cost guide). Accessed 2026-06-15.

Per the conflict hierarchy, the compliance claims here trace to the official rule (45 CFR Part 164) and the HHS/Federal Register NPRM, not to the vendor pages; vendor pages are cited only for each vendor's own current BAA availability, which is a first-party fact. Where a popular framing says a consumer tool is "HIPAA compliant", this article follows the rule: a tool is HIPAA-eligible only under a signed BAA on a qualifying configuration, and the consumer tier generally is not.