Every telehealth startup that raised money between 2020 and 2022 made the same fundamental mistake. They treated the video call as the product. The technology got slick — low-latency video, waiting rooms, virtual backgrounds, screen sharing. The clinical workflow got worse. After the 20-minute call ended, the documentation, billing, prescription routing, and follow-up coordination happened exactly the same way it always had — manually, slowly, and at the end of a twelve-hour shift.
Clinicians who practiced telehealth at scale during that period know this in their bones. The platform wasn't the problem. The platform was fine. What broke was everything that happens before and after the visit — and no one building telehealth software seemed to care about that part.
What clinicians see that engineers don't
The average telehealth visit generates roughly 90 minutes of administrative work. The visit itself takes 20. That ratio — 4.5 hours of overhead per hour of clinical care — is not a technology failure in the traditional sense. The EHR exists. The billing system exists. The fax machine, unfortunately, still exists. The problem is that none of these systems talk to each other in ways that reflect how the actual clinical workflow operates.
An engineer building telehealth software sees a video call interface connected to an appointment scheduler. A nurse practitioner running 25 telehealth visits a day sees something different: a documentation problem (the SOAP note takes longer to write than the visit took to conduct), a billing problem (the CPT code for a telehealth-equivalent service differs by payor and is still changing), and a care coordination problem (the patient who lives three states away and needs a specialist referral requires six manual steps across three systems to route properly).
These are not edge cases. They are the standard workflow for a telehealth-first practice. The operator who ran a telehealth clinic through the COVID surge — and managed the billing reconciliation, the documentation audits, the payor contract negotiations, and the staff scheduling around no-show rates — has an operational map of this problem that no amount of user interviews will produce for an engineer-first founder.
The compliance layer is your moat, not your overhead
Telehealth compliance is genuinely complex. Prescribing regulations differ by state. The Ryan Haight Act governs controlled substance prescribing across state lines. CMS telehealth coverage rules, which were liberalized during the COVID public health emergency, have continued to evolve. State medical board licensure requirements for telehealth practice vary in ways that affect everything from where a clinician can practice to what they can prescribe to whom.
Most engineer-first telehealth startups treat this compliance complexity as a cost of doing business — a legal and regulatory overhead that requires outside counsel and slows down product development. The operator founder who has lived through state licensure applications, CMS audit preparation, and payor contract negotiation for telehealth codes sees this differently.
Compliance knowledge is the barrier to entry. The platform that handles payor-specific telehealth billing correctly — that maps the right CPT and modifier codes to the right payor contract terms, automatically, without manual intervention — is worth switching to even if every other feature is identical to the incumbent. That knowledge doesn't come from reading the CMS manual. It comes from having your billing team reject a month of claims because the modifier was wrong for a single payor's policy.
This is the moat that the healthcare SaaS operator founder builds by default. The compliance layer that looks like a liability to an engineer is a structural advantage to someone who has already absorbed it operationally.
Your first customers are already in your contact list
The distribution strategy for a telehealth startup built by a clinician or practice administrator is direct and obvious. Your first ten customers are the practice managers, clinical directors, and billing coordinators at practices similar to yours — colleagues you've spoken to at conferences, in professional association listservs, in state medical association meetings. They have the same problems you have. They are not being served by the current platforms.
The second distribution channel is the telehealth network. Large telehealth platforms — the ones that contracted with thousands of clinicians during the COVID surge — created communities of practice that still exist. Clinicians who used these platforms and found them inadequate are the exact audience for a more specialized solution built by someone who understands what they actually needed.
The third channel, worth building deliberately, is the billing and revenue cycle management company. RCM firms that handle telehealth billing for independent practices are gatekeepers to hundreds of similar clients. If your platform integrates cleanly with how they work — which most platforms don't — you can reach their entire client base through one partnership conversation.
The operator founder who built and ran telehealth operations doesn't need to explain telehealth billing to the RCM firm. They speak the same language. That conversation happens in a week, not a year.
The telehealth software that actually sticks
The telehealth software that achieves high retention solves one of three problems with genuine depth: documentation, billing, or care coordination. Trying to solve all three at once is a product strategy for a company with 50 engineers. The operator founder's advantage is in knowing which of these three problems is the most acute for a specific specialty or practice type — and building that one thing extremely well.
A behavioral health telehealth practice has a different acute problem than a primary care telehealth practice. The behavioral health practice needs documentation templates that map to insurance-required treatment plan formats and produce the audit trail that state behavioral health licensing boards require. The primary care practice needs a chronic disease management workflow that tracks labs, adjusts medications, and coordinates with the specialist the patient is also seeing in person.
These are not generic software problems. They are the operational problems of specific clinical environments, and they require the insider knowledge of someone who has actually practiced or managed within those environments. The clinician-founder who spent eight years running a behavioral health practice doesn't need to research what the documentation problem is. They've filled out the form wrong in front of an auditor. They know.
← Back to blog