Insights · 11 min read
What a telemedicine app really is, the compliance work you can't skip, what drives cost, and how to scope an MVP you can actually launch.
By GGP Editorial
A telemedicine app looks simple from the outside: a patient books a slot, a doctor appears on video, the visit ends, and everyone gets a record. The demo always works. The parts that decide whether the product survives are the ones you never see in the demo: the encryption on the video stream, the audit log of who opened which record, the signed agreement with your hosting provider, and the integration that pushes a prescription to a pharmacy without a human retyping it.
I write this from the vendor side. GlobeSoft is a software company founded in 2018 with 40-plus engineers and more than 300 delivered projects, and we have built healthcare, scheduling, and video-capable products for clients across several markets. This guide covers what a telemedicine app actually is, the compliance work you cannot skip, what drives the cost, and how to scope something you can actually launch.
If you are still deciding whether to build at all, start with our piece on healthcare software development cost, which walks through where the money goes in a healthcare build.
A telemedicine app is three products wearing one name.
The patient surface is where someone books an appointment, joins a visit, and sees their history and prescriptions. The provider surface is where a doctor sees their schedule, opens a visit, writes notes, and issues a prescription. The admin surface is where your staff manages accounts, payments, and the queue when something goes wrong.
Most teams plan the patient app in detail and treat the other two as afterthoughts. That is backwards. A doctor will not use a product that makes their day slower, and your support team cannot fix anything without an admin screen. The provider and admin surfaces are the difference between a demo and a business.
There is also a version distinction worth making early. A telehealth product built for consumers who pick a doctor from a directory is a different build from a white-label tool a clinic gives its own patients, which is different again from a video feature added to an existing clinic management system. Scope is not a detail. It changes the data model, the payment flow, and the compliance work.
The visible features are the easy ones. Here is a realistic split between what a telemedicine product needs in its first release and what can wait.
| Must have in v1 | Can wait |
|---|---|
| Video and audio consultation | AI symptom triage |
| Appointment booking and reminders | Wearable device integration |
| Basic patient records | Chronic-care dashboards |
| Secure messaging | Group visits |
| e-Prescriptions (where permitted) | Insurance claim automation |
| Payments and billing | Multi-language support |
| Provider schedule and queue | Analytics and reporting |
| Admin console | Marketing automation |
The admin console is the module nobody demos and everyone needs. When a patient says the video never connected, or a payment looks wrong, your team needs a screen that shows the visit, the state of the payment, and who did what. If that screen is missing, every support ticket becomes an engineering ticket.
One note on e-prescriptions. In the United States, electronic prescribing runs through networks such as Surescripts, and controlled substances carry separate requirements under the DEA's EPCS program. In other countries the rails and rules are different. If prescriptions are part of your product, treat them as a first-week scoping item, not a checkbox at the end.
Health data is regulated data. The video call is maybe 15 percent of the build. The compliance layer is the rest, and it is where projects stall.
In the United States, the framework is HIPAA, which governs protected health information, or PHI. The practical effects: you encrypt data in transit and at rest, you log access to records, you restrict who can see what through role-based access, and you sign a business associate agreement, or BAA, with every vendor that touches PHI, including your hosting provider and your video provider.
In Europe and the UK, GDPR and the UK GDPR govern health data as a special category of personal data. The rules overlap with HIPAA in spirit, but the details, the lawful bases, and the enforcement differ.
EHR integration has its own standard. FHIR, part of HL7, is the format most electronic health record systems use to exchange data, so if your product needs to read or write into a hospital or practice EMR, plan for a FHIR integration early.
On the video itself, WebRTC is the common way to build encrypted, browser-based calls, and it is a well-supported path. Many teams also choose a managed, HIPAA-compliant video SDK to avoid building call infrastructure from scratch. Both are reasonable; the wrong move is assuming any off-the-shelf video tool is automatically fine with PHI. It is not.
None of this is legal advice, and the exact requirements depend on where you operate, where your patients live, and whether you touch prescriptions. The point is simple: compliance is a first-week topic, not a launch-week topic. We covered the same "build for the audit" logic in healthcare software development.
There are three paths, and they suit three different situations.
Buying a white-label telemedicine platform is the fastest way to market. You get a working product with the compliance handled, but you pay per user or per visit, you get little control over the roadmap, and you will eventually hit a wall when you need a feature the vendor does not offer.
Building custom gives you full control of the experience, the data, and the integrations, at a higher upfront cost and a longer timeline. This is the right call when telemedicine is the core of your business rather than a feature of it.
Extending an existing product means adding video and scheduling to a clinic management system, an EHR, or a patient portal you already run. This is often the cheapest and fastest option, because the records, the accounts, and the payment flow already exist and you are adding one surface.
The decision usually comes down to one question: is telemedicine the product, or a feature of a product you already have? Answer that first and the rest of the scoping gets easier. If you are leaning toward building, how to define an MVP before hiring developers is a good place to start.
Cost in a telemedicine build is driven by four things, in rough order of impact.
Team. A telemedicine product needs a product manager, a designer, two or three backend engineers, one or two mobile or frontend engineers, and usually a part-time security or compliance reviewer. Where the team sits changes the bill a lot: a senior engineer through a China-based team runs roughly $5,000 to $8,000 a month, against around $12,000 to $16,000 for the same role on a US salary. We break those numbers down in software development cost in China.
Compliance depth. The BAA, the encryption, the audit logging, and the access controls are not free, and e-prescribing or FHIR integration adds real time. This is the biggest hidden line item, and it grows with every extra region or feature.
Integrations. Payment processing, SMS and push notifications, a pharmacy or EHR connection, and a video SDK each add time, and each is a place where scope quietly grows.
Video infrastructure. Building your own WebRTC signaling and media handling is work. Using a managed video SDK costs money per minute but saves engineering time. Most early products should buy the video and build the product around it.
As a rough guide, a focused telemedicine MVP, with video, booking, basic records, messaging, and payments, typically lands between $50,000 and $120,000. A full platform with e-prescriptions, FHIR integration, and multi-party support runs $150,000 to $400,000 or more. These are ranges, not quotes; the only number that matters is the one from a scoped proposal. We wrote a walk-through on getting a real number in how to estimate a custom software project.
A focused telemedicine MVP runs four to six months from kickoff to a limited launch. A full platform with e-prescribing, EHR integration, and the admin tooling to support it runs eight to twelve months. Deep hospital integrations can push past that.
Plan for a discovery phase before anyone writes code, a compliance review early enough to change the architecture, and a pilot with a small group of real clinicians and patients before you open the doors. Healthcare products are tested in production in a way internal tools are not, and a pilot catches the workflow problems no specification ever does.
AI has real uses in telemedicine, but they are narrower than the pitch decks suggest.
The useful ones are transcription and routing. Turning a visit into a written note saves a doctor real time, with the patient's consent. Reading an intake form and pulling the name, date of birth, and medications off it removes data entry. A scheduler that reminds patients and nudges no-shows pays for itself fast.
The risky ones are any place a model makes a care decision. A symptom triage that tells a patient they are fine, or a summary a clinician signs without reading, is where harm happens. Keep the AI on the transcription and routing side, and keep a clinician in the loop for anything that touches care. If you want to understand where AI actually pays for itself in business software, start with how to add AI to existing business software.
Building the video before the records. Founders start with the call because that is what the demo shows. The record is the product. The video is a feature.
Skipping the BAA. You can sign BAAs after the fact, but only if your hosting and video choices support it. Changing a video provider at launch because they will not sign one is expensive.
Treating e-prescribing as a checkbox. Prescriptions have their own rails and their own rules. If they are in scope, scope them in week one.
No admin console. Your support team is the first group that will tell you the product is unfinished. Build for them early.
Assuming "HIPAA-compliant" is a certificate. It is a set of controls across hosting, code, and process. A vendor badge does not make your product compliant; your design and your operations do.
A focused MVP with video, booking, basic records, messaging, and payments typically lands between $50,000 and $120,000. A full platform with e-prescribing, EHR integration, and multi-party support runs $150,000 to $400,000 or more. See where the money goes in a custom build for the breakdown.
In the United States, if you handle patient health information, yes, and that includes signing BAAs with the vendors that touch it. Requirements in other regions, such as GDPR in Europe, are similar in intent but different in detail. Confirm the specific obligations with counsel for your market.
Buy if you need to launch fast and can live with the vendor's roadmap. Build if telemedicine is the core of your business. Extend your existing product if you already run a clinic system or patient portal and just need to add video.
Four to six months for a focused MVP, eight to twelve for a full platform. Deep hospital integrations can push the timeline past a year.
Video, booking and reminders, basic records, secure messaging, payments, and an admin console. Skip AI triage, wearables, group visits, and claim automation until you have real usage.
Usually, and it is often the cheapest path. Adding video and scheduling to a product that already has records, accounts, and payments is a smaller job than building the whole thing from nothing.
GlobeSoft is a software development company founded in 2018, with 40-plus engineers and more than 300 delivered projects for over 100 clients across the US, Brazil, South Africa, and Singapore. We build custom software, mobile apps, SaaS platforms, FinTech systems, ERP and CRM, and AI products on a stack that includes Java, Spring Boot, Go, Python, React, Vue, and Node.
If you are planning a telemedicine product, a patient portal, or a healthcare system of any kind, talk to us about your project. Send us the rough idea and we will help you figure out the build-versus-buy call, the compliance scope, and what to ship first.
Tell us what you are building and where you are today. We typically reply within 24 hours.
