Healthcare app development: a practical UK guide (2026)

To develop a healthcare app in the UK you need to do four things in order: decide whether your product is a medical device, establish your data protection position, appoint a clinical safety officer, and only then design and build. Teams that reverse that order lose months. Anything that handles health data sits inside a regulatory regime that ordinary apps do not, and that regime shapes the product rather than sitting on top of it.

We have built bespoke software for over twenty years, and what we would say about healthcare is this: the engineering is rarely the thing that holds a medical app up. The regime itself creates the delay, because classification, clinical risk documentation, UKCA marking and NHS assessment all run on external timescales. Discover any of them halfway through a build and the schedule moves, not the requirement.

Start by classifying your product

Before anything else, work out which of three categories you are in. The answer changes your budget, your timeline and your team.

Category	What it covers	What it triggers
Wellbeing or administrative	Booking, reminders, general fitness, staff rotas, practice admin	UK GDPR, good security practice
Health app handling patient data	Patient portals, care records, remote monitoring dashboards	UK GDPR special category rules, DCB0129, NHS DTAC if sold to the NHS
Software as a medical device	Anything that diagnoses, treats, calculates a dose or drives a clinical decision	MHRA registration, UK MDR 2002, UKCA marking, quality management system

The line between the second and third categories is narrower than most founders expect. An app that displays a blood pressure reading is usually not a device. An app that interprets that reading and tells the user to act on it usually is. The MHRA publishes guidance on this, and if you are close to the line, take proper regulatory advice before you write a specification. Retro-fitting device compliance to a finished product costs far more than designing for it.

The compliance layer, in plain terms

Data protection

Health information is special category data under UK GDPR. In practice this means a Data Protection Impact Assessment is expected rather than optional, you need a clear lawful basis and an Article 9 condition, and you need to be able to explain where data lives, who can see it and how long you keep it. Decide your hosting region early. Moving a live system between jurisdictions later is painful.

Clinical safety

NHS England’s information standards DCB0129 and DCB0160 cover clinical risk management for the manufacturer and the deploying organisation respectively. If your software will be used in NHS care, you will need a named clinical safety officer, who must be a suitably qualified and registered clinician, and a hazard log maintained throughout development. Appoint that person at the start. Their questions change what you build, and it is cheaper to hear them in week two than in month eight.

Selling into the NHS

The Digital Technology Assessment Criteria (DTAC) is the baseline the NHS uses when assessing a digital product: clinical safety, data protection, technical security, interoperability, and usability and accessibility. Alongside it, expect to complete the Data Security and Protection Toolkit and to hold Cyber Essentials or Cyber Essentials Plus, with ISO 27001 often requested for larger contracts. None of this is difficult in isolation. All of it takes calendar time, so run it in parallel with development rather than afterwards.

Interoperability is the feature that decides adoption

A medical app that cannot exchange data with the systems clinicians already use will not be adopted, however good the interface is. In the UK that generally means FHIR UK Core for data exchange, SNOMED CT for clinical terminology, dm+d for medicines, and NHS Login where patient identity matters. If you need GP record access, GP Connect is the route, and it comes with its own onboarding process.

Two practical points. First, integration effort is almost always underestimated, because the standard tells you the shape of the data but not the quirks of each supplier’s implementation. Second, get sandbox access early. Waiting on credentials is one of the most common causes of a stalled sprint, and it is entirely avoidable. Our note on choosing a tech stack covers how integration requirements should drive that decision rather than follow it.

How to develop a healthcare app: the sequence that works

1. Classify and scope. Device or not, NHS or private, who the users are. Write it down.
2. Discovery with real clinicians. Not a focus group. Observe a clinic. Workflows on paper never match workflows in practice.
3. Requirements and clinical risk in parallel. Your requirements specification and your hazard log should be written by the same team in the same fortnight.
4. Design for the worst conditions. Gloved hands, poor lighting, interruptions, an eight-year-old tablet on hospital wifi. Good UI and UX design in healthcare means legibility and error prevention, not visual flourish.
5. Build a narrow MVP. One pathway, done properly, beats six features half-finished. Our guide to MVP development explains how to draw that line.
6. Test with clinical users before launch. Usability failures in healthcare are safety failures.
7. Plan for the second year. Regulation changes, integrations change, and clinical safety documentation must be kept current.

What healthcare app development costs in the UK

Our published ranges apply here, with one adjustment: compliance and assurance work adds meaningfully to the total.

• Simple app, such as a patient booking or appointment reminder product with modest integration: £10,000 to £50,000.
• Mid-range app, such as a patient portal with record access, secure messaging and one or two NHS integrations: £50,000 to £150,000.
• Complex platform, such as a multi-role clinical system, remote monitoring at scale, or anything classified as a medical device: £150,000 to £1,000,000 and upwards.

UK agency day rates typically translate to £75 to £150 per hour. If you want to sanity-check a figure before you speak to anyone, our cost estimator will give you a range from a short questionnaire, and the app development cost guide explains what drives the variance.

The honest answer to “what will mine cost” is that it depends on three things: how many external systems you must connect to, whether you are a medical device, and how many distinct user roles the product supports. Those three factors move the number far more than platform choice does.

Where healthcare projects go wrong

Treating compliance as a launch task. It is a design constraint. Discovered late, it rewrites your data model.

Building for the buyer instead of the user. A trust may sign the contract, but if the ward staff find the app slower than paper, usage falls away quickly and the product does not survive contact with the ward.

Underestimating identity and access. Healthcare products have complicated permission models: clinicians, administrators, patients, carers, locums, auditors. Model this properly at the start.

Skipping the offline case. Hospital connectivity is unreliable in exactly the places clinical work happens. Decide early what the app does when the network is not there.

Choosing a partner without regulated-sector experience. Ask directly how they would work with your clinical safety officer, how they handle a hazard log, and what they expect DCB0129 to change about the way the software is documented and released. If you are picking a supplier, our guide to choosing a software development company sets out the questions worth asking.

Frequently Asked Questions

How long does it take to develop a healthcare app?

It depends far more on regulation and integration than on the size of the feature list. A simple patient-facing app with limited integration is the quickest to deliver. A patient portal with NHS integrations and clinical safety documentation takes considerably longer, because assurance work runs in parallel with the build. Anything classified as a medical device takes longer again, since regulatory assessment, quality management and clinical evaluation all sit alongside development. Integration approvals and sandbox access are the most frequent cause of slippage.

Does my medical app need MHRA approval?

It depends on what your software does, not on what sector it serves. If the app diagnoses, monitors for a clinical purpose, calculates a dose, or produces output that directly informs a clinical decision, it is likely to be software as a medical device and falls under the UK Medical Devices Regulations, requiring registration with the MHRA and UKCA marking. If it only stores, displays or transmits information without interpreting it, it usually does not. Take regulatory advice at the specification stage.

What is DTAC and do I need it?

The Digital Technology Assessment Criteria is the standard set of questions NHS organisations use to assess a digital health product before buying it, covering clinical safety, data protection, technical security, interoperability, and usability and accessibility. You need it if you intend to sell into the NHS. You do not need it for a purely private product, although working through it is still a sensible quality benchmark, and most of what it asks for is worth having regardless.

Should I build a native or cross-platform healthcare app?

For most healthcare products, cross-platform frameworks such as React Native or Flutter are a sound choice, because clinical apps rarely depend on the device features where native builds pull ahead. Native becomes the better option when you need deep integration with device hardware, background monitoring, or specific health platform features on iOS or Android. Decide based on your integration requirements and your ongoing maintenance budget, not on fashion.

Who owns the code when an agency builds our healthcare app?

That depends entirely on the contract, and you should settle it before work starts. At Make IT Simple our clients own one hundred per cent of the code, including repositories, infrastructure configuration and documentation. In a regulated setting this matters more than usual, because your clinical safety case, hazard log and technical documentation are assets you may need to produce to a regulator or an NHS assessor, potentially long after the original build team has moved on.

Where to go next

If you are working out whether your idea is a medical device, what it will cost, or how to phase the build sensibly, we are happy to talk it through without obligation. Our mobile application development and bespoke software development pages set out how we work, and if your product is specifically about remote consultations, our guide to telemedicine app development goes deeper on that pathway. When you are ready, get in touch.