Telemedicine app development: a practical UK guide (2026)

If you are planning a telemedicine app in the UK, the build itself is rarely the hard part. Video consultations, secure messaging, appointment booking, remote monitoring and prescribing workflows are all well-understood engineering. The hard part is the layer around them: UK GDPR, clinical safety standards, NHS assessment criteria, and whether your product counts as a medical device. Budget for that from day one and the rest follows.

Telehealth projects tend to come unstuck on the same point. A competent video app gets built first, and clinical governance is then retro-fitted onto it afterwards, which costs far more than doing it in the right order. Sequencing matters more than technology choice.

What separates a telemedicine app from ordinary software

Three things make healthcare builds different.

The data is special category data. Health information sits in a higher-risk tier under UK GDPR, which means a Data Protection Impact Assessment is expected, not optional, and your lawful basis needs to be established before you write code.

Clinical safety is a formal discipline. If your app will be used in NHS health or care settings, the clinical risk management standards DCB0129 (for manufacturers) and DCB0160 (for deploying organisations) apply. That means a named Clinical Safety Officer, a hazard log and a clinical safety case report. These are documents, not features, and they take real time.

You may be building a medical device. Software that diagnoses, triages, calculates a dose or otherwise informs a clinical decision can be classed as a medical device and falls under MHRA regulation. Software that simply connects a patient to a clinician usually does not. The line is genuinely narrow, so get a regulatory view early. Being told late in the build that you need conformity assessment is an expensive surprise.

Core features worth building first

You do not need everything at launch. You do need these to be correct.

Feature	Why it earns its place	Common mistake
Video consultation	The clinical event itself	Building the video stack in house rather than using a compliant provider
Secure messaging	Handles the many routine queries that do not need a call	Treating it as chat rather than a clinical record
Identity and access	Confirms who the patient is	Weak verification, no audit trail
Booking and triage	Controls clinician time	Free-for-all calendars that fill with the wrong appointments
Clinical notes and records	Continuity of care	Storing notes outside the clinical system of record
Prescribing workflow	Completes the episode	Assuming you can issue prescriptions without the right integrations and clinical governance
Payments or NHS billing	Gets you paid	Bolting on payments late and reworking the user journey
Accessibility	Legal and practical necessity	Ignoring WCAG until an audit forces it

Accessibility deserves a line of its own. Your users skew older and less digitally confident than a consumer app audience. Large touch targets, real text rather than text in images, screen reader support and a route to a phone call are not nice extras. They are the difference between a service people use and one that quietly excludes the patients who most need it. In our experience, UI and UX work on products of this kind earns its keep here rather than in visual polish.

Types of telemedicine app

Deciding which of these you are building sharpens every later decision.

• Real-time interactive. Live video or audio consultation. Highest bandwidth and reliability demands, and the type most patients picture.
• Store and forward. The patient submits images, readings or a questionnaire; a clinician reviews it later. Common in dermatology, radiology and ophthalmology. Far cheaper to run, because it removes the scheduling problem entirely.
• Remote patient monitoring. Devices or apps feed readings such as blood pressure, glucose or oxygen saturation back to a care team, with thresholds and alerts. The alerting logic is often where medical device questions arise.
• Asynchronous messaging and advice. Structured written consultation, frequently used in sexual health, mental health and repeat prescribing.
• Telerehabilitation and telenursing. Guided exercise programmes or nursing support delivered remotely, usually a mix of video, content and check-ins.

Store and forward is consistently underrated. If your clinical use case tolerates a delay, you avoid the hardest engineering and operational problems in the whole category.

Integrations that decide whether the product works

A telemedicine app that cannot exchange data with existing systems creates a second record, which means clinicians end up keying the same information twice. That alone kills adoption.

The integrations that matter in a UK context are the patient record (GP or hospital systems, typically via FHIR UK Core or supplier APIs), identity through NHS login where you are serving NHS patients, electronic prescribing, and any device or wearable feeds you rely on. Each has its own onboarding process, and those processes are usually the long pole in the schedule rather than the code. We wrote more generally about how these connections behave in our guide to API integration.

Plan integration discovery before you commit to a launch date. It is entirely normal for supplier approval to take longer than building the feature that depends on it.

What it costs to build in the UK

We publish honest ranges rather than a single number, because the variables are large. UK agency rates typically sit between £75 and £150 per hour, and our published app ranges apply to telemedicine as much as to anything else:

• Simple app, £10,000 to £50,000. A focused single-purpose tool: booking plus a compliant third-party video layer, no clinical system integration, one user type.
• Mid-range, £50,000 to £150,000. Patient and clinician apps, messaging, records, payments, one or two integrations, proper clinical safety documentation.
• Complex, £150,000 to £1,000,000 and upwards. Multi-role platforms, device monitoring, deep record integration, regulated medical device functionality, multi-organisation deployment.

Three costs are routinely left out of first budgets: the clinical safety work, penetration testing and security assurance, and the ongoing cost of keeping integrations and compliance current after launch. If you want to sanity-check a figure before speaking to anyone, our cost estimator gives a range in a couple of minutes, and our guide to app development costs in the UK breaks the variables down further.

A sensible build sequence

1. Define the clinical pathway before the product. Write down exactly what happens to a patient from first contact to outcome, including the failure cases.
2. Establish the regulatory position. Decide whether you are building a medical device, start the data protection impact assessment, and appoint a Clinical Safety Officer.
3. Design for the least confident user. Prototype and test with real patients, not colleagues.
4. Build a genuine MVP. One pathway, end to end, working properly. Our mobile app development lifecycle guide sets out how we structure this.
5. Secure and test. Independent penetration testing, encryption in transit and at rest, full audit logging. The principles in our piece on building a secure web app apply directly.
6. Pilot with one organisation. Fix what the pilot exposes before scaling.

Frequently Asked Questions

How much does it cost to develop a telemedicine app in the UK?

A focused telemedicine app with booking and third-party video typically costs £10,000 to £50,000. A fuller platform with patient and clinician apps, messaging, records and one or two integrations sits between £50,000 and £150,000. Regulated products with device monitoring or deep clinical system integration start around £150,000 and can exceed £1,000,000. UK agency rates generally fall between £75 and £150 per hour.

How long does telemedicine app development take?

A single-pathway MVP is typically a matter of months from a settled specification, whilst a multi-role platform with clinical system integration usually takes considerably longer. The variable that moves the schedule most is not engineering effort but external dependency: integration approvals, clinical safety sign-off and information governance reviews run on other organisations’ timescales, so start them in parallel with design rather than after build.

Does my telemedicine app need to comply with HIPAA?

Only if you act as a covered entity or business associate under US law, which in practice means handling protected health information on behalf of US healthcare providers or health plans. A direct-to-consumer service holding US patient data without that relationship sits outside HIPAA, though other US rules still apply. For a UK service the governing framework is UK GDPR and the Data Protection Act 2018, supported by NHS information governance requirements, the Digital Technology Assessment Criteria and the DCB0129 and DCB0160 clinical risk management standards.

Is a telemedicine app classed as a medical device?

It depends on what the software does. An app that only connects a patient to a clinician for a consultation generally is not a medical device. Software that performs triage, suggests a diagnosis, calculates a dose or interprets monitoring data to prompt clinical action often is, and then falls under MHRA regulation with conformity assessment and UK medical device marking obligations, the exact route depending on whether you are placing the product on the market in Great Britain or Northern Ireland. Take regulatory advice before development starts, not after.

Should I build a custom telemedicine app or buy an off-the-shelf platform?

Buy if your pathway is standard and you mainly need video, booking and notes: you will be live faster and cheaper. Build custom when your clinical pathway is your differentiator, when you need integration that packaged products will not support, or when you intend to license the product to others. A useful test is whether you would be comfortable if a competitor used the identical off-the-shelf system.

What technology should a telemedicine app be built with?

There is no single correct answer, but sensible defaults are React Native or Flutter for cross-platform mobile, a well-supported backend such as .NET or Node, UK-region cloud hosting, and a compliant third-party video provider rather than a bespoke streaming stack. Choose established, well-documented technology over novelty: healthcare products live for years and must remain maintainable and patchable throughout.

Where to start

If you are weighing up a telemedicine product, the most useful next step is a short conversation about the clinical pathway and the regulatory position, before anyone estimates a build. We do that as part of our consulting work, and we build the resulting products through our mobile application development and SaaS development teams. Clients own 100% of the code we write. If you would like to talk it through, get in touch.