Telemedicine App Development Cost: What Sets the Price

Custom telemedicine software costs what its scope costs. User roles, video, payments, prescriptions and compliance move the price far more than the tech stack.

I rebuilt MedicsBD, a live telemedicine platform in Bangladesh, in September 2026: web app, API, video calls, payments, prescriptions and an Android and iOS app on top, plus a move of every record from the old system. So instead of a generic price table, this guide walks through what a real platform contains, which parts cost the most and why, and the monthly bills that most quotes leave out.

Key takeaways

• Count the roles first. Patients and doctors is one product. Add clinic staff, field agents and company programmes and every screen needs rules about who sees what.
• Video is cheaper to build than to get right. Getting a call to connect is the quick part. Ringing, device checks, push and SMS fallback, and weak mobile networks are where the time goes.
• Money is the riskiest part. Revenue splits, wallets and refunds need a ledger and protection against double payment.
• Compliance depends on where you operate. In the US, every vendor that handles patient data needs a business associate agreement under HIPAA.
• Budget for running costs: servers, video bandwidth, SMS, storage, payment fees and app store accounts, every month.

What a telemedicine platform actually contains

Here is what MedicsBD runs today. Your project may need less, but this is the honest list of what "a telemedicine app" turns into once real patients and doctors use it:

• Roles: patients (with family members on one account), doctors, desk doctors, admins, and agents who book for patients in villages and factories.
• Scheduling: doctor schedules, time slots and serial numbers, booked online in a few steps.
• Video consultations on a self-hosted LiveKit server, with the patient's phone ringing through a live notification, web push, and SMS as a fallback, and a device check before each call.
• Payments through local gateways, mobile wallets and an in-app wallet, with every paid visit split between doctor, agent and platform.
• Prescriptions written on screen and printed to PDF in Bangla, each with a QR code anyone can scan to check it is genuine.
• Notifications and jobs: SMS, email and push sent from a background queue, and real-time chat.
• Admin and reports: appointments, payments, withdrawals, users, packages, templates and reports.
• A mobile app for patients and doctors, built with Expo and React Native on the same API.

The cost drivers, biggest first

1. User roles and permissions

Each role multiplies the work: its own dashboard, its own rules and its own tests. Before MedicsBD went live I wrote a test matrix of role against endpoint, 90 API tests, and loaded every page as every role. That audit found discount codes anyone could list and sandbox payment settings that would have stayed on in production. That kind of checking is part of the price, and skipping it is how health data leaks.

2. Video calls

You have three realistic options:

• A hosted video API billed per participant minute. Fastest start, a bill that grows with usage.
• Self-hosted LiveKit (what MedicsBD uses) or Jitsi. A fixed server bill and data on your own infrastructure, but someone has to run it. My LiveKit self-hosting guide shows what that involves.
• Zoom or Google Meet links. Cheapest, but patients leave your app, and you control almost nothing about the experience.

Whichever you choose, the expensive part is the experience around the call: a doctor starts a call, the patient's phone rings even with the app closed, the patient's camera and microphone are checked first, and a dropped call can be rejoined.

3. Payments and money movement

Taking one payment is simple. Splitting it between a doctor, an agent and the platform, keeping wallets, paying out withdrawals and handling refunds is accounting software. On MedicsBD I found and closed a race where a gateway's browser redirect and its server callback could both confirm the same payment and pay the doctor twice. The same class of bug exists with Stripe; my post on Stripe webhook idempotency shows the fix.

4. Prescriptions and documents

A prescription is a legal document, not a screenshot. Layout, the doctor's registration details, the right fonts for your language and a way to verify it all take time. For Bangla, printing the on-screen layout to PDF with Puppeteer was the only reliable way I found to get correct text from Node.

5. Compliance and security

The rules depend on where your patients are. In the US, HIPAA applies, and since the pandemic-era enforcement discretion ended (the transition period closed on 9 August 2023), providers need video and hosting vendors that will sign a business associate agreement. In the EU, health data is a special category under GDPR. Other countries have their own laws. Plan for encryption in transit and at rest, audit logs, access by role, data retention rules and backups you have actually restored. Ask a lawyer about your market; I build the technical side.

6. Mobile apps

A shared API makes the mobile app much cheaper: MedicsBD's Expo app runs on the same API as the web platform. The extra work is push notifications, store review rules, offline cache and forced updates. Open the store accounts early and in the clinic's own name. Apple's developer program costs $99 a year, and organisation accounts need a D-U-N-S number, which can take days to weeks. The MedicsBD app was finished and tested on real devices before those accounts were ready.

7. Moving from an old system

If you already have patients, the migration is its own project. MedicsBD moved 64 MySQL tables to PostgreSQL with a script that compared row counts for every table, kept old password hashes working so nobody had to reset, and redirected old links and printed QR codes. Old prescription QR codes still verify. Budget for this, or you will pay for it later in support calls. I wrote up the exact traps in migrating MySQL to PostgreSQL without losing data.

8. Languages

MedicsBD's interface has over 1,200 strings in Bangla and English, chosen per user. A second language touches every screen, every email and SMS template and every PDF. Decide early, even if you launch in one language.

Three scope levels to compare quotes against

1. Pilot clinic. One clinic. Patients, doctors and an admin. Doctor schedules and booking, video calls, one payment method, a prescription PDF and email or SMS reminders. Web app first. This proves patients will book and pay.
2. Doctor marketplace. Many doctors and specialities. Doctor onboarding and verification, wallets, payouts and revenue splits, reviews, packages and subscriptions, and a mobile app.
3. Programmes and partners. Agents booking for patients, kiosk calls from shared devices, company health programmes, lab orders, integrations with other systems and several languages.

Ask every vendor to price the same level, with the same list. A quote that is half the others usually means a level-one price for a level-three wish list.

The monthly bills after launch

• Servers: the app, the database and backups. A VPS with a fixed bill is fine for a launch.
• Video: per-minute charges on a hosted API, or a media server and TURN bandwidth if you self-host.
• SMS: per message, and it adds up fast with reminders and call fallbacks. Push notifications are free to send.
• Storage: reports, prescriptions and images. S3-compatible storage such as RustFS keeps this cheap on your own server.
• Payment fees on every transaction, from your gateway.
• Upkeep: security updates, monitoring, and small changes doctors ask for in the first months.

Questions to ask any developer before you sign

• Who owns the code, the servers and the store accounts? (It should be you.)
• Where does patient data live, and who can access it?
• How is video billed when you have 10 times more calls?
• What stops a payment being confirmed twice?
• When did you last restore a backup, and how long did it take?
• If I have an old system, how will you prove every record moved?

My checklist for hiring a freelance developer has more questions that apply to any project.

Frequently asked questions

How much does a telemedicine app cost?

It depends on scope: the number of roles, how payments work, video, prescriptions, languages and whether you need mobile apps. My general web app MVP starts at $1,500, but a telemedicine product usually has several workflows, so I give a fixed quote per milestone after a short scope call.

How long does it take to build telemedicine software?

A pilot for one clinic is a matter of weeks. I rebuilt MedicsBD's web platform and API during September 2026, but its requirements were already known from the old system. A new product with open questions takes longer, mostly in decisions, not code.

Can I use Zoom or Google Meet instead of building video?

For a quick pilot, yes. You lose control over the experience, patients leave your app, and you depend on another company's terms for health data. For a real product, embed video with LiveKit or a hosted video API.

Do I need HIPAA compliance?

If you handle health data for patients in the US as a covered entity or business associate, yes. Other countries have their own rules. Either way, encryption, audit logs, access control and tested backups are good practice for any health app.

Should I build the website or the mobile app first?

Start with a web app that works well on phones, on an API built to serve a mobile app later. Patients can book from any phone on day one, and the native app reuses the same API when you are ready.

Planning a telemedicine platform?

I build telemedicine and booking platforms end to end: web app, API, video, payments, prescriptions, mobile apps and the server they run on. See my web development services or tell me about your clinic and I'll send you a scope and a fixed quote.