Healthcare app rescue in 2026: the first two weeks without a vendor

TL;DR

Healthcare app rescue in 2026 starts with one question: can anyone still build and ship this app? When the build will not compile, regressions keep returning and the previous team has left, the first two weeks decide whether you fix, refactor or rebuild. The stores raised the stakes: since April 28, 2026 Apple accepts only uploads built with Xcode 26, and Google Play updates must now target API level 36.

• Days 1 to 2: revoke the old team's access to your code and patient data.
• Days 2 to 5: get one signed build into TestFlight and a Google Play internal track.
• Days 5 to 10: spend a fixed timebox on the bugs patients and clinicians feel.
• Days 10 to 14: write the fix, refactor or rebuild decision, with evidence.
• Bill the rescue as time and materials until the backlog is known.

Why healthcare apps break after the team leaves

A healthcare app rarely dies in one incident. It decays. The people who knew why the build worked leave, and the next release breaks something that worked last quarter.

Founders describe it in operational terms. "Haven't been able to generate a build," one telehealth founder wrote: the Expo output was close to 150MB when it should have been around 30MB. Document upload had stopped working, and visit history "worked at one point." Another founder was paying about $50,000 a month and had "a basic app after like eight months." A family facing care app kept crashing on Android while its only developer had no time to look.

CISQ's 2022 report on the cost of poor software quality put accumulated US technical debt at about $1.52 trillion. A rescue is where your share comes due.

What it costs to keep an app off this path is broken down in our guide to healthcare app maintenance cost.

The 2026 store deadlines that turn a broken build into an outage

An app nobody can build is, this year, an app nobody can update.

• Apple: since April 28, 2026, uploads to App Store Connect must be built with Xcode 26 or later using the iOS 26 SDK, per Apple's SDK minimum requirements.
• Google Play: since August 31, 2026, new apps and updates must target API level 36, with an extension available to November 1, 2026. Existing apps targeting API level 34 or lower only reach devices running that Android version or lower.
• Expo: SDK 55, released February 25, 2026 with React Native 0.83, removed Legacy Architecture support.

If the last team shipped on an old Expo SDK with legacy native modules, the clinician's urgent fix now waits behind a toolchain migration. For a care app, that is a patient safety question.

How we built this two week playbook

• Every step comes from healthcare engagements where someone else wrote the code, as recorded in our discovery and pipeline notes.
• Each step ends in an exit criterion you can check without reading code.
• Clients stay unnamed unless they appear as a published case study on our site.
• Any group of our own data with fewer than three data points is not published.

Mercury Development sells this work and has built custom software since 1999, so the examples are our own.

The two week rescue at a glance

Days 1 to 2: lock down access and patient data

Before anyone touches code, find out who can still touch your data: cloud consoles, store accounts, signing certificates, database passwords.

The HIPAA Security Rule lists termination procedures for ending access to electronic protected health information when an arrangement ends. If the old vendor was a business associate, its contract should require it to return or destroy the protected health information it still holds, where feasible.

The first 48 hours:

• Move the repository, App Store Connect and Google Play Console under accounts your company owns.
• Rotate every key and every secret found in source files.
• Recover the signing certificates and Android upload key, or plan their reset.
• Ask the departing vendor, in writing, to return or destroy patient data.

In one inherited stack we reviewed, secrets sat in source code, production ran on a single server with no redundancy, and deployment was manual. All of it is a day 1 problem.

If the outgoing vendor is still reachable, the full handover order is in our guide to switching healthcare app vendors.

Days 2 to 5: make it compilable, then deployable

The first engineering goal is boring. For the telehealth app above, our first recommendation was to make it compilable and deployable, then discuss the roadmap. Compilable means a clean checkout builds on a fresh machine and runs on a real device. Deployable means a signed build reaches TestFlight and a Google Play internal track through a pipeline your side can rerun.

Typical blockers: an SDK pinned below what current Xcode supports, native modules written for the old React Native architecture, build scripts that lived on one engineer's laptop. An oversized binary, like that 150MB build, usually means unpruned assets.

The exit criterion is a build number. No build by day 5 is the most important finding of the rescue.

Days 5 to 10: a timebox on the bugs patients feel

Once you can ship, spend a fixed window on what patients and clinicians feel. We proposed a two week timebox on top priority bugs for that telehealth app, and its list was typical: document upload, visit history, appointment cancellation handling and chat.

• Rank bugs by clinical and revenue impact, ahead of whoever complained last.
• Pair each regression fix with a test that would have caught it.
• Stop when the window ends and report what closed, what did not and why.

Count the fixes that broke something else. That count feeds the day 14 decision.

Days 10 to 14: fix, refactor or rebuild

By day 14 you hold a short memo with three options and evidence for each.

• Fix in place: the pipeline works, regressions stay fixed, new features land without breaking old ones.
• Refactor in stages: specific modules carry the debt. Isolate and replace them one at a time.
• Rebuild: fixes keep breaking unrelated features, or the architecture blocks platform requirements.

Our Fitness Bank engagement took the first path. The bank arrived with a published first version, and fixing the issues hindering its clients came before any redesign. Distiller took the third. An aging codebase was rebuilt on React Native with a CI/CD pipeline that made shipping a routine operation instead of a multi day event.

If the memo points to a rebuild, the choice between a full and a phased replacement is in big bang rewrite vs incremental replacement.

Signs your app was not built for scale

Signs we look for in a first review, drawn from inherited healthcare code we have assessed.

• One screen controller holds most of the logic. One iOS review we ran called it a massive view controller.
• Business rules and strings are hardcoded, with no localization support.
• Automated test coverage is close to zero. One backend we reviewed sat at about 4%.
• Secrets live in source files or committed environment files.
• Production runs on a single server with manual deployment.
• Messaging is spread across several queues and brokers with no clear owner.
• Compiler strictness has been switched off.
• Each new feature costs more than the one before.

Two or three of these are ordinary debt. Five or more, and the day 14 memo should price a staged replacement.

Why a rescue runs on time and materials

Fixed scope assumes you know the scope. In a rescue you do not. For the telehealth app above we recommended time and materials because of the backlog size and the iterative Scrum delivery it needed.

A fixed price on an unknown codebase gets padded or disputed. Time and materials with short timeboxes gives you weekly evidence and a clean exit. Structure makes it safe:

• A fixed first window with a written deliverable.
• A weekly demo of a working build.
• A burn report against the ranked bug list.
• The right to stop after any window.

Fixed price becomes reasonable later, for a well specified module, once a pipeline and tests exist.

How each contract model carries risk in a healthcare build is covered in our guide to healthcare software engagement models.

Which rescue path fits your situation

The build fails and the team is gone: start at day 1.

The app ships but regressions keep returning: go straight to the timebox, with a regression test per fix.

Android crashes while iOS holds up: scope a platform parity rescue with its own timebox.

The vendor is still there but expensive and slow: run the assessment in parallel and keep the old team until your build works without them.

Fundraising or a large contract is close: get the day 14 memo before the sales promise.

What our healthcare pipeline records show

These are our own numbers, counted by hand from healthcare and telehealth pipeline and discovery records.

In around 25% of those accounts, the first conversation was about an app or codebase someone else had built. Among them, in around 80% our notes recorded a specific code health or pipeline risk before any feature estimate: a broken build, a structural flaw, untracked prior work, or debt that made estimates unreliable.

Our portfolio shows the same pattern. Around 30% of the case studies on our site began with someone else's code, from Tonal, where we joined an existing iOS and Android codebase alongside other engineering teams, to the workflow automation system we have maintained for a medical billing client since 2006.

Read both shares as a floor.

Where a two week rescue falls short

Two weeks buys control and an honest diagnosis. It does not buy a healthy product.

Device integrations or a regulated component can take more than one window to understand. Some source code never comes back from the previous vendor, and the first weeks go to reconstruction. And a rescue team cannot replace a product owner: if nobody on your side ranks the bugs, the timebox ends with a well documented list.

Rescues work when the team stays stable after the crisis. Our about page states we can update team structure within 2 weeks of a customer request, and our 100+ QA engineers can own the regression tests a rescue leaves behind.

Written by Alexey Rodionov, Lead Front-end Developer at Mercury Development since 2020. Alexey is a Google Developer Expert in Web Technologies and a Chromium contributor whose code ships in Chrome DevTools, Google's Bubblewrap and Microsoft PWABuilder. The code reviews behind this article's takeover checklist come from the engineering practice he works in.

Send us the app that stopped building

Tell us what fails today: the build, the release, or the features that used to work. Add which accounts and keys you still control. We will reply with the first two weeks we would run and what we would need from your side.