A stalled health platform starts serving patients in four months
An inherited digital health platform moved from a stuck build to live patient use in four months, with the remaining compliance work completed inside the next two.
Value delivered
The platform began serving patients in four months, followed by the remaining compliance work inside the next two months.
A patient-facing platform cannot create value while it is stuck in development.
This digital health platform had been inherited mid-build. Technical debt had accumulated across the backend, patient experience and clinician workflow, while the evidence needed for healthcare use was still part of the work. The business did not need another strategy document. It needed a working service that patients and clinicians could use, with the safety and security case built alongside it.
We brought the platform into live use in four months. The remaining compliance work followed inside the next two months. The result was not simply a completed software project. It was a patient and clinician service that could operate in the environment it was designed for.
Client background
Our client is a digital health company whose platform supports patients and clinicians across NHS care systems. It is a two-sided service: patients need a simple way to take part, while clinicians need a dependable place to review information, prepare reports and act on it.
That means the platform has to work as one service. A mobile app without a clinician workflow leaves the care team with manual work. A clinician portal without a usable patient experience leaves the service without reliable information. Both sides also carry the expectations that come with patient-facing software.

Business challenge
The platform was stuck mid-build and carrying technical debt that nobody could clear through the existing setup. The work that remained was not one isolated feature. It included:
- a backend that could support the service;
- a patient mobile experience;
- a clinician portal;
- report generation for professional documentation;
- engagement mechanics, rewards and vouchers;
- security, privacy and clinical safety evidence.
Each part depended on the others. A report workflow is not useful if the information cannot reach the clinician. A patient journey is not sustainable if the care team cannot see what is happening. A working demo is not enough if the platform cannot answer the security and clinical safety questions that arrive before live use.
The business needed a route out of the stuck state without treating compliance as an unknown task at the end. The first useful milestone was a working service. The next was evidence that the service could be operated responsibly in regulated care.
Implementation
We rebuilt the platform as a connected backend, patient app and clinician portal. The patient side gave people a clear way to take part in the programme. The clinician side gave professionals a dedicated place to see information, generate reports and manage the workflow around it.
We added AI-assisted report generation as a bounded part of the service. The system prepares a draft from the information available in the platform. The clinician remains responsible for reviewing, correcting and signing the final document. That distinction matters in healthcare: speed helps the professional, but the system must not quietly turn a generated draft into an unreviewed clinical record.
Rewards, gamification and voucher handling were built into the patient journey rather than treated as decorative additions. The service depends on repeat participation, so the mechanics that encourage that behaviour have to work with the patient and clinician workflows around them.
The delivery also included the evidence required for healthcare use. Cyber Essentials and the NHS Data Security and Protection Toolkit addressed the security and data-protection expectations. DCB 0129 and DCB 0160 clinical safety cases made the clinical risks and controls explicit. ISO 27001, HIPAA requirements, a data protection impact assessment and client security questionnaires were part of the delivery context.

Why it was difficult
The platform had to move in two directions at once. It needed to become usable quickly enough that patients could benefit from it, but it also needed the controls and evidence that prevent a fast release from becoming an unsafe one.
The work was difficult because the bottleneck was structural. The patient app, clinician portal, report workflow, engagement features and compliance evidence could not be finished as separate projects with separate definitions of done. They had to agree on the same underlying service and survive the same operational review.
That is also why the four-month milestone matters. It shows the platform moved from inherited and stalled to usable patient-facing service. It does not mean every regulated software project takes four months. The useful lesson is that recovery needs a working vertical path through the product, not a longer list of unfinished components.
Value delivered
- The inherited platform began serving patients in four months.
- The remaining compliance work was completed inside the following two months.
- Patients and clinicians received connected experiences instead of separate manual workflows.
- The platform included bounded AI-assisted reporting, with professional review and sign-off kept in the process.
- Security, privacy and clinical safety evidence was delivered alongside the working platform.
- The live service could continue to be extended rather than remaining a one-off recovery project.
The business outcome was a change in state: the platform stopped being a stuck build and became a service people could use. The delivery evidence made that change credible to the organisations that had to review it.

What this means for your business
If a useful system has stalled, the most expensive part may not be the code already written. It may be the time lost while patients, staff or customers continue using the old manual process, and while the evidence needed for approval remains undefined.
The same recovery pattern applies to a client onboarding workflow, a professional reporting system or a document process blocked by security review. Reconnect the working path, define the human approval where it belongs and produce the evidence during delivery. The goal is not to finish every feature before anyone can use the system. It is to create a safe, useful service and make the next step obvious.
Related: Platform recovery · Compliance-ready delivery · Digital health and NHS suppliers