The Hidden Cost Of Telemedicine Apps Is Not Always Development
I’ve been thinking about something that does not get discussed enough in healthcare MVP planning.
Most founders ask:
How much will it cost to build the app?
But for telemedicine products, I think the better question is:
What will every visit cost after launch?
Because once you add automation, the cost is not only the first build.
Every visit can create small ongoing costs. For example:
A patient fills intake.
The system reviews symptoms.
The doctor joins the call.
Audio gets transcribed.
A visit note is prepared.
Follow-up instructions are created.
Remote monitoring data is checked.
The record may need to connect with another system later.
Each step can be useful.
But each step also adds cost, review time, storage, security decisions, and support work.
That is why I’m starting to think healthcare MVPs should not add automation just because it sounds advanced.
They should ask:
- Does this save the doctor real time?
- Does this reduce manual work for the clinic?
- Does this create a safer patient record?
- Does this need human review?
- What does it cost every time it runs?
- What happens if the output is wrong?
- Can the clinic afford this at scale?
A feature can look small on the roadmap. But if it runs on every consultation, it becomes part of the business model.
This is especially true for things like:
- Clinical notes
- Voice-to-text
- Remote patient monitoring
- Patient follow-up
- EHR/FHIR planning
- HIPAA-ready storage
My current takeaway:
For a telemedicine MVP, I would rather build one automation that clearly saves the clinic time than five smart features that increase the cost of every visit.
How have other founders think about this? When you add automation to a product, do you calculate the ongoing cost per user/action early? Or do you mostly think about development cost first?
I expanded on this in more detail here, if helpful.
What I found interesting is that the post starts with a cost question and ends with a product-design question.
A lot of the examples you listed definitely create ongoing costs.
What I'm less certain about is whether the expensive features end up being the ones that hurt a telemedicine product the most.
Sometimes the cost shows up directly on the bill.
Sometimes it shows up somewhere else and only looks like a cost problem later.
That's the part I'd be most curious about.
Interesting. I suspect the most expensive feature isn’t always the one with the highest API bill. In fact, it is the one that quietly increases friction across the workflow. Have you seen specific examples where a feature looked inexpensive to build but became costly once it was in production?
A few come to mind, but I think it'd be easier to explain properly than squeeze into a thread.
What's the best email to reach you on?