Software for a regulated sector costs more than the same features would cost anywhere else, and almost none of the difference is in the features. It goes on evidence: the documents, assessments, named responsibilities and audit trails that prove the thing is safe to use. Budget for the evidence as a line item or it will arrive as an overrun.
The good news for anyone pricing this work is that the requirements are published, specific and knowable in advance. The overrun is avoidable. What is not avoidable is the work itself.
Why does regulated software cost more to build?
Because the deliverable is larger than the software. In health, finance and safety-critical work you are producing a product plus a file that demonstrates how the product was designed, what could go wrong, who decided it was acceptable and what happens when it fails. That file is the part most first-time buyers have not costed.
Take the NHS as the clearest example, because its rules are public. Compliance with the clinical risk management standard DCB0129 is not optional for suppliers: NHS guidance states plainly that a digital technology which cannot meet DCB0129 cannot be placed on the market. Its companion standard, DCB0160, applies to the organisation deploying the system. Both require risk management to start at the earliest stage of the development lifecycle and continue through maintenance and decommissioning.
That last clause is the expensive one. Risk management that runs from before the first line of code until the system is switched off is not a phase you can add at the end.
What do you actually have to produce?
The artefacts, not just the software. For NHS work the developer side of DCB0129 requires you to produce and maintain:
- A clinical risk management system, documented as a system rather than as a policy nobody follows
- A clinical risk assessment for the product, with hazards identified and mitigations recorded
- Governance arrangements showing who owns risk decisions and how they are signed off
- Evidence that the staff doing the risk work have the competence and training to do it
- Findings presented to the deploying organisation, so their DCB0160 work can build on yours
Beyond that sits the wider Digital Technology Assessment Criteria, which bundles clinical safety with data protection, technical security, interoperability and usability, overlapping the Data Security and Protection Toolkit. BS EN 62304 on medical device software lifecycle processes is not mandated by DTAC but is commonly expected where the product is a medical device. The DTAC moved to a new home on digital.nhs.uk and the previous version of its form is retired from 6 April 2026, so confirm the current version before you scope rather than working from a saved PDF.
Where does the extra cost actually land?
Before the build and after it, mostly. In our experience the pattern looks like this:
The middle row is the one that surprises people. Writing the feature is unchanged. Proving which requirement it satisfies, which test covers it and who approved the change is the overhead, and it applies to every change for the life of the product.
Can you avoid the cost by starting unregulated and adding compliance later?
Usually not, and attempting it is the most expensive route we see. Retrofitting a risk management file onto a finished product means reconstructing decisions nobody recorded, from people who have moved on, against a codebase that was not built for traceability. The rework often exceeds what doing it properly would have cost.
There is a legitimate version of the phased approach: build a genuinely non-clinical tool first, with a clear boundary, and treat the regulated product as a separate build that reuses what it can. That works when the boundary is real. It fails the moment a clinician starts making decisions using your unregulated tool.
Does the supplier need to have done it before?
For regulated work, yes, and ask for the artefacts rather than the anecdote. A supplier who has genuinely done this can show you a clinical risk management file, name a safety officer and describe a hazard they identified and mitigated. One who has not will learn on your budget and your submission deadline.
Our own healthcare work is why we can price this honestly. PatientGo supports clinical trials that have scaled from hundreds of patients to tens of thousands, Voice-Care works inside hospitals, and the MedTech Breakthrough Award 2026 and our Syneos Health testimonial exist because that documentation was in place, not because the apps looked good.
How should you budget for it?
Treat compliance as a workstream with its own cost, run alongside the build from week one. Price it separately from features so you can see what it is, and so nobody trims it when the budget tightens. If a supplier's quote for regulated work looks like their quote for ordinary work, they have not read the standards, and that is a commercial risk sitting in your project rather than a saving. The general breakdown of where build money goes is in what it actually costs to build an app, and regulated work sits above those bands rather than inside them.