Build versus buy for telehealth infrastructure, with an honest cost model
A practical cost model for building or buying telehealth infrastructure, with categories and variables you can replace with your own numbers.
Vayra Platform team · · 5 minute read
Every telehealth operator eventually asks whether to build the stack or buy it. The question usually gets answered by instinct: engineers want to build, finance wants to buy, and nobody writes down the full cost of either. This article gives you a model to fill in with your own numbers.
A note before the math. We sell telehealth infrastructure, so we have a point of view. We have tried to keep the model fair, and every figure below is an illustrative assumption for you to replace. None of the numbers are Vayra prices or Vayra results.
What "the stack" actually includes
Before costing anything, list what you would be building. A complete telehealth operation usually needs:
- Patient experience. A storefront, program pages, a configurable intake builder, account management, messaging, and refill flows.
- Clinical tools. An electronic health record, clinician queues, asynchronous review, synchronous video for states or programs that require it, and e-prescribing.
- Clinician supply. Licensed clinicians in every state you serve, plus credentialing, scheduling, and quality review.
- Pharmacy fulfillment. Order routing, status tracking, and shipping updates with one or more pharmacies.
- Payments and billing. Subscriptions, refunds, dunning, and a processor that accepts your category.
- Operator dashboards. Funnel, clinical throughput, fulfillment, revenue, and retention reporting.
- Compliance and security. Access controls, audit logs, encryption, BAAs, a risk assessment, and incident response.
- Integrations. Labs, identity verification, email and SMS, and analytics that stay out of PHI.
Teams that estimate a build often cost only the first item and part of the second. The rest is where budgets break.
The build cost model
Use this table as a template. Replace each assumption with your own figure.
| Cost category | Your variable | Illustrative assumption |
|---|---|---|
| Engineering salaries, fully loaded | engineers × loaded cost | Assume 4 engineers at $180,000 = $720,000 |
| Product and design | headcount × loaded cost | Assume 1 person at $160,000 = $160,000 |
| Security and compliance work | risk assessment, penetration test, policies, counsel | Assume $60,000 |
| Cloud hosting on HIPAA-eligible services | monthly cost × 12 | Assume $3,000 × 12 = $36,000 |
| Third-party services | e-prescribing, labs, identity, messaging | Assume $4,000 × 12 = $48,000 |
| Year one build total | sum of the above | $1,024,000 |
That total covers software only. It does not include clinicians, a pharmacy relationship, or the MSO-PC legal structure, which you need under either option.
Year two and beyond
Software you build is software you maintain. Regulations change, e-prescribing vendors update their APIs, browsers change, and security patches never stop. A common planning assumption is that ongoing maintenance costs a meaningful share of the original build every year. If you assume 25 percent of the year one engineering and product cost ($880,000), that is $220,000 a year before you add a single new feature. Replace 25 percent with your own estimate.
The cost nobody puts in the spreadsheet: time
The largest build cost is often the months you are not live. Use this formula:
Cost of delay = months of additional build time × expected monthly contribution margin
For example, assume a build takes 6 months longer than a platform launch, and your expected contribution margin once live is $50,000 a month. The cost of delay is 6 × $50,000 = $300,000. Your numbers may be higher or lower. The point is to put a figure in the column instead of leaving it blank.
The buy cost model
Buying is not free, and the visible price is rarely the whole price. Here is the equivalent template.
| Cost category | Your variable | Illustrative assumption |
|---|---|---|
| Platform or license fee | monthly fee × 12 | Assume $5,000 × 12 = $60,000 |
| Per-encounter or per-patient fees | volume × fee | Assume 6,000 encounters × $15 = $90,000 |
| Implementation and configuration | one-time fee | Assume $10,000 |
| Internal staff to run the platform | headcount × loaded cost | Assume 1 operations lead at $120,000 = $120,000 |
| Visible year one total | sum of the above | $280,000 |
The hidden lines
Now add the costs that do not appear on the order form. These are the ones to ask about directly.
| Hidden cost | Your variable | Illustrative assumption |
|---|---|---|
| Medication margin added by the vendor | fills × margin per fill | Assume 6,000 fills × $20 = $120,000 |
| Payment processing override | processed volume × override rate | Assume $1,500,000 × 1% = $15,000 |
| Data export or exit fees | one-time | Assume $25,000 |
| Hidden year one total | sum of the above | $160,000 |
In this illustration, the true year one cost of buying is $280,000 + $160,000 = $440,000, more than half again the visible price. Your vendor may have none of these hidden lines, or different ones. The only way to know is to ask for each in writing.
Putting the two side by side
Using the illustrative assumptions above:
| Build | Buy | |
|---|---|---|
| Year one direct cost | $1,024,000 | $440,000 |
| Cost of delay | $300,000 | $0 (by assumption) |
| Year one total | $1,324,000 | $440,000 |
| Year two ongoing (before new features) | $220,000 plus hosting and services | platform, encounter, and staff costs again |
Do not take the conclusion from our numbers. Take it from yours. There are real cases where building wins.
When building makes sense
- Your workflow is your product. If the way you deliver care is the differentiator, and no platform supports it, owning the code may be worth the cost.
- You already have a healthcare engineering team that has shipped and maintained regulated software.
- Your volume is large enough that per-encounter fees would exceed the cost of a dedicated team over a few years.
- You need deep integration with an existing hospital or health system environment that a platform cannot reach.
When buying makes sense
- Speed matters and the cost of delay is high.
- Your differentiation is brand, audience, or clinical focus, not the software underneath.
- You do not want to own compliance engineering as a permanent function.
- You want to test programs or states before committing a large fixed cost.
A middle path: buy the backend, own the data
The build versus buy framing hides a third option. You can buy infrastructure while keeping the things that would make building attractive: your brand, your clinicians if you have them, your payment processor, and full ownership of your data with a documented schema. If you later decide to build, a clean export means you are not starting over.
That is how Vayra Platform is designed. We run our own direct-to-consumer practice on the same stack, so the clinical, pharmacy, payment, and dashboard pieces are in daily use. You can bring your own processor, bring your own clinicians or use ours, and export your data. Our pricing page describes how we price, and our developer documentation covers the REST endpoints and webhooks if you plan to build on top of it.
If you want to fill in this model with your own numbers and pressure-test it with us, Book a demo.