Short answer: healthcare software costs about $30,000 to $70,000 (roughly £24,000 to £56,000) for a patient portal or booking app, $70,000 to $180,000 (roughly £56,000 to £145,000) for a telehealth platform, $90,000 to $250,000 for a system that integrates with electronic health records, and $200,000 upwards for anything that qualifies as a medical device. Compliance typically adds 20 to 40 percent to the build, and it is the part that cannot be deferred to version two.
Healthcare software is not harder to write than other software. It is harder to ship. The engineering is ordinary; the regulatory classification, the data handling rules, the integration standards and the evidence you have to produce are what separate a six-month project from an eighteen-month one.
The single most expensive mistake in this field is discovering your regulatory tier late. Below is how to work out which tier you are in, what each one costs, and how the build actually runs.
One thing to be clear about before we start: what follows is engineering guidance, not legal or regulatory advice. Classification decisions, particularly around medical devices, need a regulatory specialist signing them off in your specific market.
Work out your tier first
Almost every cost and timeline question in healthcare software resolves to one question: how close does your product get to clinical decision-making?
| Tier | Examples | Regulatory weight |
|---|---|---|
| Administrative | Booking, billing, staff scheduling, intake forms, practice websites | Data protection rules apply, device rules do not |
| Patient-facing and clinical data | Patient portals, telehealth, remote monitoring dashboards, care coordination | Full health data regime, security scrutiny, interoperability expectations |
| Software as a medical device | Diagnosis, treatment recommendations, triage decisions, image analysis | Device regulation, clinical evidence, quality management system |
Tier one is a normal software project with strict data handling. Tier two is where most digital health products sit and where this guide concentrates. Tier three is a different kind of business, with a regulatory pathway that usually costs more than the software.
The boundary between two and three is narrower than founders expect. Software that calculates a dose, triages a symptom, or tells a clinician what is probably wrong tends to fall into the device category even when it is described as decision support. If your product makes or materially influences a clinical decision, get it classified before you write code.
The compliance map
United States: HIPAA
HIPAA governs protected health information. If you are a covered entity, or a business associate handling data on behalf of one, it applies. The practical engineering consequences are consistent.
You need a signed business associate agreement with every vendor that touches protected health information, including your cloud provider. The major clouds all offer these, but only for a defined subset of their services, so check the list before you architect on a service that is not covered.
You need access control that is role-based and individually attributable. Shared logins are not acceptable.
You need audit logging of who accessed which record and when, retained and reviewable. This is a first-class feature, not a debug log.
You need encryption in transit and at rest, plus a documented process for breach notification, workforce training and periodic risk assessment. The Security Rule is a management regime, not a checklist you satisfy once.
United Kingdom and Europe
Health data is special category data under UK GDPR and GDPR, which means you need both a lawful basis and a separate Article 9 condition to process it, a data protection impact assessment for anything high risk, and clear data residency answers.
Selling into the NHS adds two specific gates. The Data Security and Protection Toolkit is an annual self-assessment your organisation completes. The Digital Technology Assessment Criteria covers clinical safety, data protection, technical security, interoperability and usability, and buyers will ask for it. Clinical risk management under DCB0129 for manufacturers is also commonly required, which means appointing a clinical safety officer and producing a hazard log.
None of this is optional if you want NHS customers, and all of it takes calendar time rather than engineering time, so start it in parallel with the build rather than after it.
Commercial requirements
Separately from law, enterprise buyers will ask for SOC 2 Type II or ISO 27001. These are not legally required and are frequently the actual blocker on a deal. Type II needs an observation window, commonly three to twelve months, so the timing matters: start the controls early or you will pass the audit months after you needed it.
Interoperability: HL7 and FHIR
If your product exchanges data with hospital or clinic systems, you will meet HL7 v2 and FHIR. FHIR is the modern standard, resource-based and accessed over a normal web API, and it is what new integrations should target. HL7 v2 is older, message-based and still extremely common in hospitals.
The honest warning: FHIR being a standard does not mean two FHIR implementations behave the same way. Each vendor supports a different subset of resources, with different extensions and different authentication. Budget integration work per system, not once. A first integration with a major EHR vendor is commonly six to twelve weeks, and the second one is not free.
Healthcare software development cost
| Product | What it includes | Typical cost (USD) | Typical cost (GBP) | Timeline |
|---|---|---|---|---|
| Patient portal or booking app | Accounts, appointments, forms, reminders, payments | $30,000 to $70,000 | £24,000 to £56,000 | 3 to 5 months |
| Telehealth platform | Video consultation, scheduling, clinical notes, payments, roles | $70,000 to $180,000 | £56,000 to £145,000 | 5 to 9 months |
| EHR-integrated system | The above plus one or more live EHR integrations, clinical workflows, audit | $90,000 to $250,000 | £72,000 to £200,000 | 6 to 12 months |
| Software as a medical device | Regulated product with clinical claims, evidence and a quality system | $200,000 to $600,000+ | £160,000 to £480,000+ | 12 to 24 months |
These are industry-typical ranges for 2026. Tier one and two products sit broadly in the same territory as the platform tier in our web app development cost guide, with compliance work on top.
What compliance adds
| Item | Typical cost | Notes |
|---|---|---|
| Security and compliance engineering | 20 to 40 percent of build | Audit logging, access control, encryption, data lifecycle |
| Penetration test | $5,000 to $15,000 per round | Expect to run one before launch and annually after |
| SOC 2 Type II, first year | $30,000 to $80,000 all in | Tooling, auditor, plus internal engineering time |
| Quality management system for a device | $40,000 to $120,000+ | ISO 13485 and IEC 62304 lifecycle evidence |
| Clinical safety documentation | Weeks of specialist time | Required for NHS supply |
The percentage range on the first row is the one that matters. It is not a tax on the project. Audit trails, granular permissions, consent handling and data retention rules are features, and they take real engineering.
How the build runs
Discovery and regulatory scoping. Before architecture, establish your tier, your markets, which data you genuinely need, and who your integration targets are. Collecting less data is the cheapest compliance decision available to you.
Architecture and data model. Segregate identifiable data, design the audit trail into the data layer rather than bolting it on, and decide retention and deletion behaviour early because retrofitting deletion across a live clinical system is painful.
Integration. Start the EHR or lab integration earlier than feels reasonable. Access to a test environment is often the long pole, and it is frequently a procurement conversation rather than a technical one.
Build in reviewable slices. Two-week sprints with working software, so clinicians can react to something real. Clinical users will tell you within ten minutes of use what a requirements document failed to capture over six weeks.
Validation and evidence. Test evidence, traceability from requirement to test, and documented risk assessment. For tier three this is formal and continuous, not a phase at the end.
Launch and monitoring. Uptime monitoring, incident process, a support path for clinicians, and a plan for the first time something goes wrong at three in the morning.
Where healthcare builds go wrong
Discovering the device classification late. The most expensive failure mode in this field, because it can invalidate the architecture, the claims, the marketing and the go-to-market plan at once.
Collecting data because it might be useful. Every extra identifiable field increases your risk surface, your consent complexity and your breach exposure. Justify each one.
Treating audit logging as a later feature. It has to be designed into the data layer. Adding it afterwards means touching every write path in the system.
Assuming one EHR integration teaches you the rest. Budget each integration separately.
Designing for clinicians without clinicians. Documentation burden is the number one complaint clinical users have about software. If your product adds clicks to a consultation, it will not be used regardless of how good the underlying idea is.
Leaving SOC 2 until a customer asks. The observation window means the answer to "can you have it by next quarter" is usually no.
Bottom line
Healthcare software is a normal engineering project wrapped in a regulatory one. Establish your tier before you write code, budget 20 to 40 percent on top for compliance engineering, start your integrations and your audit timeline early, and collect the minimum data the product genuinely needs. Get those four right and the build behaves like any other custom software project.
Book a free call and we will work out which tier your product falls into, what that means for the budget, and give you a fixed price for the build.