Building a digital health app for the UK market costs between £60,000 and £400,000 and takes 18 to 30 months to reach NHS-ready status. The price depends entirely on how the Medicines and Healthcare products Regulatory Agency (MHRA) classifies your app as Software as a Medical Device (SaMD). A simple wellness or booking app sits outside medical device rules and can ship in three to six months for £40,000 to £90,000. A clinical decision-support or AI diagnostic tool is a Class IIa or higher medical device, demands UKCA marking, DCB0129 clinical safety, a Digital Technology Assessment Criteria (DTAC) pass, UK GDPR compliance and NHS integration, pushing budgets to £200,000 and beyond. Fewer than 5% of healthcare apps meet UK regulatory standards on first attempt. The single biggest cost driver is leaving compliance until late: retrofitting it adds 30% to 50% to the build. This guide maps the full regulatory stack, costs, timeline and commercial pathway.
Last updated: June 2026
Yes, the UK digital health market is one of the most attractive in the world for serious health innovators, and it is forecast to exceed £8 billion by 2027. The reasons are structural rather than hype. The NHS App now has more than 30 million registered users, which means you are building on top of a digital identity layer that already reaches half the adult population. There is genuine government appetite for digital-first care, real budgets behind elective recovery and remote monitoring, and a single regulator-led pathway that, once you understand it, gives you a defensible moat.
That moat is the point. The barrier to entry that makes the UK market frustrating for a beginner is the same barrier that protects you once you are through it. A consumer wellness app faces a crowded global App Store. A UKCA-marked, DTAC-passed, GP Connect-integrated chronic disease tool faces almost no one, because fewer than 5% of healthcare apps clear the bar. The honest rule here: if your product is genuinely clinical, the regulation is not a tax, it is your competitive advantage.
Our view, having built automation and software systems for UK businesses for over a decade, is that founders consistently underestimate two things and overestimate one. They underestimate the time to reach NHS procurement, and they underestimate the cost of clinical evidence. They overestimate how much the technology itself costs. The app is rarely the hard part. The compliance, the evidence and the commissioning pathway are where projects stall or die.
Here is who the UK market rewards right now:
If your idea sits in one of those bands and you can articulate the clinical or financial benefit to a commissioner in one sentence, the market is absolutely worth building for. If it does not, you are building a consumer app that happens to mention health, and you should price and plan accordingly.
The type of health app you are building determines your MHRA classification, your regulatory burden, your cost and your timeline before you write a single line of code, which is why this is the most important decision you will make. An app that gives users general wellness information is not a medical device. An app that interprets data to inform a diagnosis or treatment decision almost certainly is. That single distinction can move your budget by £200,000 and your launch date by a year.
The deciding question is what the software does with health data. If it stores, displays or forwards information, it is usually outside medical device rules. If it analyses, interprets, calculates a dose, flags a risk score or supports a clinical decision, it falls under the UK Medical Device Regulations 2002 and needs UKCA marking. The intended purpose you state in your documentation, not your marketing copy, is what the MHRA judges you on.
The table below maps the common UK health app categories to their likely classification, the core regulations they trigger, a realistic 2026 cost band and a rough timeline to NHS-ready. Treat the classification as indicative: borderline cases need formal advice, and the MHRA can disagree with an optimistic founder.
| App type | Likely MHRA class | Core UK requirements | Cost band (£) | Time to NHS-ready |
|---|---|---|---|---|
| Wellness / fitness / habit | Not a medical device | UK GDPR, accessibility, app store rules | £40k - £90k | 3 - 6 months |
| Appointment booking / admin | Not a medical device | UK GDPR, DSPT, NHS Login optional | £60k - £120k | 4 - 8 months |
| Telemedicine / video consult | Borderline / Class I | DTAC, UK GDPR, DSPT, clinical safety | £90k - £180k | 9 - 15 months |
| Mental health / digital therapeutic | Class I or IIa | UKCA, DCB0129, NICE evidence, DTAC | £120k - £250k | 14 - 24 months |
| Chronic disease / remote monitoring | Class IIa | UKCA, DCB0129, GP Connect, FHIR, DTAC | £150k - £300k | 16 - 28 months |
| Clinical decision support / hospital | Class IIa / IIb | UKCA, DCB0129/0160, ISO 13485, DTAC | £180k - £350k | 18 - 30 months |
| AI diagnostic / screening | Class IIa / IIb / III | UKCA, ISO 42001, clinical trial, DTAC | £200k - £500k+ | 24 - 36 months |
Be sceptical if a development agency quotes you a flat £50,000 for a "telemedicine app" without first asking what the software does with patient data. That number is a consumer app price. A genuine clinical product carries documentation, testing, clinical safety and integration costs that a generic app shop simply does not account for. The classification conversation should happen on day one, not after you have built the wrong thing.
The full UK regulatory stack for a clinical health app has six layers: MHRA medical device classification and UKCA marking, the UK Medical Device Regulations 2002, clinical safety standards DCB0129 and DCB0160, UK GDPR and data protection, cyber security and quality certifications, and NHS-specific assurance through DTAC and the Data Security and Protection Toolkit (DSPT). You do not always need all six, but you need to know which apply before you scope a budget.
Each layer answers a different question. The device layer asks "is this safe and does it do what you claim". The clinical safety layer asks "what happens to a patient if it goes wrong". The data layer asks "are you handling the most sensitive personal data on earth correctly". The assurance layer asks "is the NHS allowed to buy and deploy this". Miss one and you can build a technically excellent app that no NHS trust is permitted to touch.
| Layer | What it covers | Who owns it | When it applies |
|---|---|---|---|
| MHRA SaMD classification + UKCA | Is the app a medical device, and which risk class | MHRA + UK Approved Body | Any app analysing or interpreting health data |
| UK MDR 2002 | Conformity assessment, technical file, intended purpose | Manufacturer (you) | All medical devices placed on the UK market |
| DCB0129 (developer) + DCB0160 (deploy) | Clinical risk management, hazard log, Clinical Safety Officer | Manufacturer + deploying organisation | Any health IT system used in health or care |
| UK GDPR + DPA 2018 + DPIA | Lawful basis, data minimisation, patient rights | Data controller | Always, for any app touching personal data |
| DSPT, Cyber Essentials Plus, ISO 27001/13485/42001 | Security, quality management, AI management | Manufacturer | NHS deployment and higher-risk devices |
| NHS DTAC | Combined assurance gate for NHS adoption | NHS organisation assessing you | Selling into NHS England settings |
A few points that catch founders out. UKCA marking has replaced CE marking as the conformity route for the Great Britain market, though transitional recognition of CE marks has been extended; check the current MHRA position before you assume which mark you need. MHRA Class IIa conformity assessment, where an Approved Body reviews your technical file, typically takes 6 to 18 months, and that clock runs in parallel with development, not after it. DCB0129 is not optional paperwork: it requires a named, suitably qualified Clinical Safety Officer (CSO), a clinical risk management system, and a maintained hazard log. The honest rule is that clinical safety is a role and a process, not a document you generate at the end.
The AI layer is the fast-moving one. If your app uses machine learning to inform clinical decisions, the MHRA's Software and AI as a Medical Device programme and the international ISO 42001 AI management standard now shape what good looks like: explainability, change-control for models that learn, bias testing across demographic groups, and clear human oversight. If you are building an AI diagnostic tool and your prospective partner cannot discuss model change-control and post-market performance monitoring, walk away. Our own AI builds for regulated UK clients lean heavily on documented human-in-the-loop design for exactly this reason, and you can see how we approach it on our AI automation agency page.
NHS DTAC, the Digital Technology Assessment Criteria, is the standard baseline assessment that NHS and social care organisations use to decide whether a digital health product is safe and suitable to buy, and you pass it by evidencing five components: clinical safety, data protection, technical security, interoperability, and usability and accessibility. DTAC itself is not a certification you hold permanently; it is a questionnaire and evidence pack that a commissioning NHS organisation reviews. Getting through it cleanly typically takes 2 to 4 months of focused work, far longer if you start from scratch.
The five components map directly onto the regulatory stack, which is why doing the stack properly makes DTAC almost mechanical, and skipping it makes DTAC a nightmare. Here is what each component actually demands:
The stance we take with every health client is this: build the evidence as you build the product, and DTAC becomes a packaging exercise rather than a rescue mission. The teams that fail DTAC are almost always the ones who treated it as a final-stage checklist. Accessibility is the clearest example. WCAG 2.1 AA cannot be bolted on; it dictates colour contrast, focus order, screen-reader semantics and touch-target sizing from the first design sprint. Retrofit it and you are rebuilding screens.
| DTAC component | Key evidence required | Common failure |
|---|---|---|
| Clinical safety | DCB0129 hazard log + CSO sign-off | No qualified Clinical Safety Officer appointed |
| Data protection | DPIA + DSPT "Standards Met" | DPIA written after launch, not before processing |
| Technical security | Cyber Essentials Plus + pen test report | No independent penetration testing |
| Interoperability | FHIR UK Core conformance | Proprietary data formats, no FHIR mapping |
| Usability / accessibility | WCAG 2.1 AA audit + user research | Accessibility ignored until QA stage |
One practical tip: ask your prospective NHS partner early which version of the DTAC and which local supplementary requirements they apply, because integrated care boards sometimes layer their own checks on top. A clean DTAC pack that a trust can review without coming back with twenty questions is worth weeks of procurement time.
You integrate with NHS systems through a defined set of national APIs - NHS Login for patient identity, the Personal Demographics Service (PDS) for verified patient records, GP Connect for primary care data, and HL7 FHIR UK Core as the data standard that ties them together - and each integration carries its own onboarding, assurance and cost, ranging from £8,000 for NHS Login to £45,000 for full GP Connect. These are not casual REST APIs you wire up in an afternoon. Each requires registration, technical conformance testing and, in most cases, a connection agreement with NHS England.
NHS Login is usually the first integration founders need, because it gives patients a single, verified, secure sign-in tied to their NHS identity. It removes the burden of you verifying who a patient is and underpins trust. GP Connect is the bigger lift: it lets your app read structured data from a patient's GP record, such as medications, allergies and problems, which is transformative for chronic disease and medicines apps but comes with serious assurance overhead. PDS gives you verified demographics so you are not storing your own unreliable copy of a patient's details.
FHIR (Fast Healthcare Interoperability Resources) is the connective tissue. The UK Core profile of HL7 FHIR R4 defines how clinical concepts are structured so that data flowing between your app and NHS systems means the same thing on both sides. Building FHIR-native from the start is the single best architectural decision a UK health app can make. Retrofitting a proprietary data model to speak FHIR later is expensive and error-prone.
| Integration | What it gives you | Typical cost (£) | Onboarding effort |
|---|---|---|---|
| NHS Login | Verified patient identity and secure sign-in | £8k - £18k | Moderate, well-documented |
| Personal Demographics Service (PDS) | Verified patient demographics | £10k - £25k | Moderate |
| FHIR UK Core APIs | Standardised clinical data exchange | £15k - £40k | High, ongoing conformance |
| GP Connect | Read access to primary care records | £20k - £45k | High, full assurance process |
| NHS App integration | Distribution to 30M+ users | Variable, partnership-led | Very high, gated |
Our honest advice on sequencing: integrate the minimum you need to prove value, then expand. Many founders try to integrate everything at once and burn six months and £80,000 on connections they did not yet need for their first commissioning conversation. Start with NHS Login if you need verified patients, layer PDS and GP Connect when a specific use case demands them, and treat NHS App distribution as a later-stage prize rather than a launch requirement. If your roadmap also touches custom back-office data flows, the same FHIR-first discipline applies to your internal systems, which is where a well-designed custom CRM or integration layer earns its keep.
A UK health app costs between £60,000 and £400,000 to build, with most genuine clinical products landing in the £80,000 to £180,000 mid-market band and AI diagnostic tools running £200,000 to £500,000 and beyond, but the headline number hides the real story, which is that compliance, integration and evidence often cost as much as the software itself. Founders who budget only for design and development typically run out of money before DTAC, because they did not account for the layers underneath.
The cleanest way to think about cost is by phase rather than by feature, because compliance and evidence are continuous workstreams, not line items. Here is a realistic breakdown for a mid-market Class IIa chronic disease app at roughly £160,000 total.
| Phase | What it covers | Typical share | Indicative cost (£) |
|---|---|---|---|
| Discovery and regulatory scoping | Classification, intended purpose, DPIA, architecture | 8 - 12% | £14k - £20k |
| Design and accessibility | UX, WCAG 2.1 AA, clinical user research | 12 - 18% | £20k - £28k |
| Core development | App, backend, FHIR data layer, NHS Login | 35 - 45% | £56k - £72k |
| Clinical safety and compliance | DCB0129, hazard log, CSO, technical file | 12 - 18% | £20k - £28k |
| Security and testing | Pen test, Cyber Essentials Plus, QA | 8 - 12% | £14k - £20k |
| DTAC and NHS integration | GP Connect, DTAC pack, DSPT | 10 - 15% | £18k - £24k |
Two numbers should change how you plan. First, retrofitting compliance adds 30% to 50% to the total. An app built without DCB0129, FHIR or accessibility baked in costs far more to drag through DTAC than one designed for it from the start, because you are rebuilding rather than documenting. Second, maintenance runs around 15% to 20% of the build cost per year. A £160,000 app carries roughly £24,000 to £32,000 of annual cost for hosting, security patching, clinical safety reviews, regulatory updates and integration upkeep. Medical device software is never "finished"; it is maintained as long as it is in use.
Our blunt view on cheap quotes: a £30,000 "NHS app" quote is a red flag, not a bargain. The price tells you the supplier has not priced clinical safety, accessibility, FHIR or DTAC, which means you will pay for those later at a premium, or you will fail assurance and never sell to the NHS at all. The right question to ask a partner is not "how cheap" but "show me your clinical safety process and a DTAC pack you have shipped". If you want a feel for how we scope and price regulated builds, our software development service and mobile app development pages explain the approach, and we always start with fixed-quote discovery so the regulatory cost is visible before you commit.
You get a digital health app commissioned and paid for by generating clinical evidence to NICE standards, passing DTAC, and then selling into the right NHS budget holder - an integrated care board (ICB), an NHS trust, a GP federation, or directly to patients privately - and this commercial pathway, not the technology, is where most UK health apps fail. A brilliantly built, fully compliant app that nobody is contractually obliged to pay for is a very expensive hobby. The teams that succeed plan the money before they plan the product.
Evidence is the currency. The NICE Evidence Standards Framework for digital health technologies sets out what level of clinical and economic evidence you need depending on what your app claims to do. A wellness app needs little. A digital therapeutic claiming to reduce anxiety needs randomised or comparative study evidence. A tool claiming to cut hospital admissions needs real-world evidence and a health-economic case showing it saves the system money. Commissioners buy outcomes and savings, not features. If you cannot say "this saves an ICB £X per patient per year" with evidence behind it, you are not ready to be commissioned.
There are four realistic routes to revenue in the UK, and most successful products use more than one over time:
| Route | Who pays | Evidence needed | Sales cycle |
|---|---|---|---|
| NHS commissioning (ICB/trust) | NHS budget holder | NICE ESF + DTAC + economic case | 9 - 24 months |
| GP / primary care | GP federation or practice | DTAC + time-saving evidence | 3 - 9 months |
| Private / B2B2C | Insurer, employer, pharmacy | Outcomes data, ROI case | 2 - 6 months |
| Direct to patient | The patient | Trust signals, reviews | Immediate |
Our strong opinion, and the gap almost every competitor guide leaves out: build the commercial model before the build, and use private or B2B2C revenue to fund the slow march to NHS commissioning. Plenty of strong UK health products launch privately, gather real-world evidence and outcomes data from paying customers, then walk into NHS conversations with proof rather than promises. There is also a post-market obligation here that founders forget: as a medical device manufacturer you must run post-market surveillance and report adverse events to the MHRA. That vigilance system is both a legal duty and, handled well, a source of the very real-world evidence that wins your next contract.
The Softomate digital health implementation process runs in five stages over 14 to 30 months, with regulatory, clinical safety and development workstreams running in parallel rather than in sequence, and every engagement begins with a fixed-quote discovery so you see the full regulatory cost before you commit a single development pound. We are a London-based software and AI automation agency in Stanmore (HA7), and we build regulated systems the way they should be built: compliance designed in from stage one, not bolted on at the end.
We do not take a fixed monthly retainer and hope. We scope, we fix-quote each stage, and we make the regulatory burden visible up front so there are no late surprises. Here is how the five stages work.
| Stage | Focus | Typical duration | Key deliverable |
|---|---|---|---|
| 1. Discovery and scoping | Classification, DPIA, fixed quote | 4 - 8 weeks | Regulatory roadmap + fixed quote |
| 2. Design and research | Accessibility UX, clinical safety start | 6 - 12 weeks | Tested prototype + hazard log |
| 3. FHIR-native build | App, backend, NHS integration | 5 - 12 months | Working product + technical file |
| 4. Security and assurance | Pen test, DSPT, DTAC pack | 2 - 4 months | DTAC-ready evidence pack |
| 5. Launch and post-market | Rollout, surveillance, maintenance | Ongoing | Live app + support agreement |
Pricing is transparent. Discovery and regulatory scoping starts at £6,000 and gives you a fixed quote for the whole programme before you commit further. A straightforward booking or wellness build starts from around £45,000. A mid-market Class IIa clinical product typically runs £120,000 to £250,000 fully assured, and AI diagnostic builds are quoted individually after discovery. Every stage is fixed-quote, so you are never billed for a runaway clinical safety process or a surprise integration. If automation, voice or chatbot capability is part of your patient experience, we bring that in-house too, from AI chatbot development for triage and patient support to business process automation for the back office. Talk to us through our contact page and we will tell you honestly whether your idea is a three-month build or a three-year programme before you spend anything.
Only if your app is a medical device. If it interprets health data, calculates a dose, flags a risk or supports a clinical decision, it needs UKCA marking and MHRA registration. Pure wellness, information or booking apps are not medical devices and do not need MHRA approval, though they still need UK GDPR compliance.
Between 18 and 30 months for a genuine clinical product reaching NHS-ready status. Simple wellness or booking apps can launch in three to six months. The variation comes from MHRA classification, clinical safety work, NHS integrations and DTAC, which run as parallel workstreams alongside development rather than after it.
DCB0129 is the clinical safety standard for the manufacturer who develops the health IT system; it requires a hazard log, a clinical risk management system and a Clinical Safety Officer. DCB0160 is the matching standard for the organisation that deploys the system. As a developer you own DCB0129; your NHS partner handles DCB0160.
Yes, if your app is a health IT system used in health or care, DCB0129 requires a named, suitably qualified Clinical Safety Officer with appropriate clinical and risk-management competence. This person owns the clinical risk management process and signs off the safety case. It is a defined role, not a box to tick at the end of the build.
DTAC itself has no direct fee; the cost is in the evidence behind it. Assembling a clean DTAC pack usually takes two to four months if your clinical safety, data protection, security, interoperability and accessibility work is already in place. Starting from scratch can take far longer and add tens of thousands in retrofit cost.
For the Great Britain market, UKCA marking is the conformity route for medical devices, though recognition of CE marks has been extended under transitional arrangements. Northern Ireland follows different rules. Always check the current MHRA position, as the timelines and recognition of CE marks have changed several times since Brexit.
Integration with the NHS App, which has over 30 million registered users, is possible but gated and partnership-led rather than a self-service API. Most products start with NHS Login for verified identity, then add PDS and GP Connect as needed. NHS App distribution is best treated as a later-stage prize once your product is assured and proven.
NHS Login integration typically costs between £8,000 and £18,000, depending on the verification level you need and your existing architecture. It is one of the more straightforward NHS integrations and is well documented. GP Connect is far more involved at £20,000 to £45,000 because of its full assurance and connection-agreement process.
You need clinical evidence at the level the NICE Evidence Standards Framework sets for your app's claims, a passed DTAC, and ideally a health-economic case showing the NHS saves money. Commissioners buy outcomes and savings, not features. A digital therapeutic needs comparative study evidence; a wellness app needs very little.
Yes. Building on the HL7 FHIR UK Core data standard from day one is the single best architectural decision for a UK health app. It makes NHS integration, interoperability and DTAC dramatically easier. Retrofitting FHIR onto a proprietary data model later is expensive, slow and a common cause of failed assurance.
Building a digital health app for the UK comes down to four decisions made early. First, your MHRA classification, which sets your cost band from £60,000 for a wellness app to £400,000-plus for AI diagnostics. Second, designing compliance in from stage one, because retrofitting clinical safety, FHIR and accessibility adds 30% to 50% to the bill. Third, a FHIR-native architecture with the right NHS integrations, from £8,000 for NHS Login to £45,000 for GP Connect. Fourth, the commercial pathway: clinical evidence to NICE standards, a passed DTAC, and a clear answer to who pays, whether that is an ICB, a GP federation, a private partner or the patient. Get those four right and you join the fewer than 5% of health apps that meet UK standards. Get them wrong and you build something nobody is allowed to buy. The technology is rarely the hard part; the regulation and the route to revenue are.
If you are ready to scope a UK-compliant health app properly, start with a fixed-quote discovery from our London software development team and we will map your MHRA class, regulatory stack and realistic budget before you commit a development pound.
Written by Deen Dayal Yadav, Founder of Softomate Solutions, a London-based software development and AI automation agency in Stanmore (HA7). With over 12 years building software and automation systems for UK businesses, including regulated and data-sensitive sectors, he leads a team that designs compliance and clinical safety into products from the first sprint rather than bolting them on. Softomate Solutions is registered at Companies House and specialises in software development, AI automation, custom CRM and NHS-ready digital systems. Learn more about the team and how we work on our about page.
We protect the real names of all clients featured in examples and case studies. Every testimonial is from a real client.
More from the blog
Work with us
Book a free 30-minute discovery call with DD and get a personalised automation roadmap.
Softomate Solutions Limited
Deen Dayal Yadav
Online
We use essential cookies to keep the site running. With your permission, we also use analytics cookies to understand how visitors use our site so we can improve it. No data is sold. Privacy Policy
