Ship · App rescue & takeover
App rescue and takeover: when another team built your app and left, we audit the code, recover the accounts and keys, stabilise it and take it forward. It starts with five working days of reading the code on read-only access, so you get facts instead of opinions: what is broken, what is risky, and for each part of the app whether to fix it, refactor it or rebuild it. Then we take it over in a planned order, keeping what works and releasing nothing we cannot roll back.
Updated
At a glance
Sounds familiar?
Apps arrive for a takeover in a handful of predictable ways. None of them means the app is worthless; most of the code in most rescued apps is worth keeping. Each situation has a usual cause and a sensible first step.
Usually behind it: A freelancer or agency moved on, often with the only copy of something important: a signing key, a server password, a store account in their name. Until those are back in your hands, every update depends on someone who has left.
First step: List what is in your name today, then audit what is in the code.
Usually behind it: No automated tests, tightly coupled code and no staging copy, so every change is tried for the first time in production, by your users.
First step: Tests around the paths that break most, before any more fixes.
Usually behind it: A permission without a reason, a missing account-deletion flow, payments taken the wrong way, or a reviewer who cannot sign in. Each resubmission costs days of review.
First step: Read the rejection against the rules and the code; fix the cause, not the wording.
Usually behind it: The store account, domain, server or code repository belongs to the previous team, not to your company. Whoever holds them can, in practice, switch your product off.
First step: Recover what can be recovered, in your name, before anything else changes.
Usually behind it: Queries without indexes, everything loaded at once, work done on every request that should run in the background. It gets worse with every new user.
First step: Measure the slow paths on real data before changing a line.
Usually behind it: Rewrites are sometimes right and often not. A quote to rebuild everything rarely comes with the reasons for each part, or with what the old code does that nobody wrote down.
First step: A second opinion, area by area, with the evidence written down.
What you need from the old team
A takeover is only as good as what the previous team hands over. Some items are critical: without them, updates stall or the app cannot be rebuilt. Others save weeks. Tick what your company holds today, in its own name. The list is the same one we hand over when a project leaves us. If you can tick every critical item, a takeover can start with the audit; if not, recovering them is the first job, and it is worth doing whoever ends up maintaining the app. The full version, item by item, is our agency handover checklist.
Most departing teams are cooperative when the request is specific and complete. If some items never arrive, the audit tells you which ones matter most and what can be rebuilt or reset without them. Words that come up here are explained in our glossary: handover, app signing and secrets management.
The five-day audit
Every takeover starts with an audit, because a quote made without reading the code is a guess. Read-only access is enough, nothing is changed, and you get findings with the file and line they come from.
Day 1
Read-only access to the repositories, and a short call about what worries you: the crash, the rejection, the slowness, the bill. Your worries decide where we read first. We also try to build and run the app from its source, because whether that works is itself a finding.
Day 2
How the app is put together, how data is modelled and moves, where the business rules live, and what happens at the edges: errors, retries, time zones, money. This is where most expensive problems hide.
Day 3
Sign-in and permissions, secrets in the code, known vulnerabilities in dependencies, outdated packages, and what the tests actually prove, as opposed to what their names suggest.
Day 4
Each finding written with its file and line, ranked by severity, with the effort to fix it. A verdict for each area: fix, refactor or rebuild. Anything urgent is flagged to you the same day, not saved for the report.
Day 5
A walkthrough with your team, questions answered, and a fixed quote to fix the app or take the project over. The report is yours to take to any team, and you are under no obligation to hire us for the work.
A standard audit covers one app or one backend of up to about 50,000 lines; an app and its backend together take a little longer. The price and the larger size are on the code audit page. See the code audit. It is a careful code review at the scale of a whole product, with the technical debt priced rather than just named.
Fix, refactor or rebuild
Whole-app verdicts are almost always wrong. A sign-in flow can be fine while the payment code needs rebuilding. So each area gets its own verdict, with the evidence and the effort, and you decide in what order to spend. The doors below are the three options; the table says when each one is right and what it risks.
| FixKeep it, correct it | RefactorKeep what it does, change how | RebuildReplace it, area by area | |
|---|---|---|---|
| Choose it when | The structure is sound and the problems are specific bugs | It works, but every change is slow and risky | The design cannot do what the product now needs |
| Typical signs | Clear code, a few broken paths, missing checks | Duplicated logic, giant files, no tests, tangled modules | Wrong data model, security built on sand, a dead framework |
| What happens next | Fixes released one by one, each with a test | Tests first, then the code reshaped behind them | A new version built beside the old, data migrated, then switched |
| Main risk | Fixing symptoms of a deeper problem | Changing behaviour by accident | Losing the hidden rules the old code got right |
Effort is given as a range for each area, with what would move it up or down. A range is honest: an estimate for code someone else wrote carries more uncertainty than one for code we wrote, and the report says where that uncertainty lives instead of hiding it in one confident number.
A rebuilt area usually means moving data across, which is planned like any data migration: copied, checked and switched with a way back. When the verdict for most areas is rebuild, the work becomes a build project; see web app development or Flutter app development.
The first 90 days
After the audit, the takeover runs in a fixed order. New features come last on purpose: a team that ships features on an app it cannot yet rebuild or roll back is gambling with your users. Your plan is written for your app; this is its usual shape. Small apps move through it faster and large ones slower, but the order does not change.
Stabilise Days 1–30
Settle Days 31–60
Improve Days 61–90
Every week of a takeover you get a short note: what we recovered, what we changed, what we found and what is next. Nothing is changed without a way back, and anything that could interrupt your users is scheduled with you first. Servers come with the takeover too: see deployment and hosting. Tests are written alongside, and a fresh QA pass before the first big release is cheap insurance; automated tests keep it that way.
Evidence, not opinions
We have not published a client takeover yet, so we will not pretend to. What we can show is the work a takeover is made of: reading claims about code against the code, untangling problems nobody could explain, clearing security findings without hiding them, and handing a platform over with nothing lost. Each note links to where the full story is written, so you can check it rather than take our word for it.
In July 2026 Trainr commissioned a technical review of the marketplace we built. We checked every one of its 27 claims at the exact file and line it cited, answered each with a verdict and a time to close, and dismissed none without a code-level check. We also reported a problem the review had missed.
Trainr case studyTwo of the review's items were new features rather than defects: push notifications and UAE VAT. For VAT we listed the decisions the business had to make first, rather than guessing at tax rules in code. Separating defects from wishes is half of any takeover: it decides what is fixed now and what is planned as new work.
Trainr case studyTrainr's iPhone uploads had failed since 25 May 2026 with what looked like a permissions problem. Reading the app record through the App Store Connect API showed a renamed identifier. Reverting it fixed the uploads. The lesson for takeovers: read the system of record before trusting an error message.
Store launch serviceOn a backend we maintained, every dependency finding was closed by an upgrade, a replacement or removing an unused package, with the integration tests kept passing.
Maintenance and supportWhen Google rejected Pakka's driver app because the reviewer was locked out by a one-time-code limit, the fix was on the server, not in the app. The same bundle was resubmitted the next day, and the app is live on Google Play.
Store launch serviceOn 13 August 2026 we handed Trainr to the client's own developer: accounts, signing material, deploy and rollback runbooks, environment templates for all four repositories, and a full export of the media bucket.
Agency handover checklist
After the takeover
A takeover ends with a stable app, a runbook and a choice. None of the three is the default; the right one depends on how much the product needs to change and who you want changing it. Whichever you pick, the accounts, keys and documents stay in your company's name, so the choice can change later without another rescue.
The app keeps working, stays accepted by the stores and gets small improvements every month, from the engineers who now know it. Platform deadlines are planned months ahead, and you get a report every month.
Maintenance and supportLarger features, or the areas the audit marked for rebuilding, planned and built as proper projects with designs first. The takeover's tests and runbook mean the new work starts on solid ground.
Mobile app developmentIf you are hiring your own developers, we hand the app over the way we would want to receive it: accounts, keys, runbooks and a written record of what is open, with time set aside for their questions.
Agency handover checklistIn a fixed order. First a five-day audit on read-only access, so both sides know what is being taken over. Then accounts and keys moved into your company's name and old secrets rotated, then the app rebuilt from source by us so we know we can release it, then monitoring, then urgent fixes. Only after that do refactors and new features start. You get a short written note every week, so you can see what was recovered and changed, and nothing goes live without a way back.
Start with what is already in your company's name: store accounts, domain, servers. Our agency handover checklist lists the rest. A compiled app from the store is not source code, so code that only exists on someone else's machine cannot be recovered by us. Who must hand over what is usually set by your contract, which is a question for a lawyer; we will tell you exactly what we need and why, so that conversation is short.
Usually neither for the whole app. Most rescued apps have parts worth keeping and parts that are not, so we give a verdict per area: fix, refactor or rebuild, each with its effort and its risk. Rebuilding everything throws away the business rules the old code got right, which are often the hardest part to rediscover. When a rebuild is right, we rebuild one area at a time beside the old one, so the product keeps working while it changes underneath.
Yes. Repeated rejections usually come from a few causes: permissions without a stated reason, a missing account-deletion flow, payments taken through the wrong system, or a reviewer who cannot sign in. We read the rejections against the store rules and the code, fix the causes and resubmit with a clear note. If the store accounts are not in your name yet, moving them comes first, because a resubmission from the wrong account only delays the real fix.
JavaScript and TypeScript codebases: Node.js and Express backends, React and Next.js web apps, React Native mobile apps and MongoDB data, plus Flutter apps. If your app is built on something else, we say so before the audit rather than learn on your product.
Once we can rebuild and release the app from source ourselves, which is the first job after the audit. Until then, any release is a gamble on build steps nobody has written down. Urgent fixes found by the audit go out first, each with a way back. If something is actively harming users, such as a failing payment, we can usually contain it on the server side while the full release path is being rebuilt.
We tell you what the code says: what works, what is risky and what it costs to fix. We do not write reports about people. Most problems in rescued apps (the technical debt) come from deadlines, changing requirements and missing tests, not from bad intentions, and blame does not make the app any better. If you are in a dispute with the previous team, the report is factual and dated, which is usually more useful to you than an opinion would be.
Yes. Many takeovers are partial: a backend whose developer left while an in-house team keeps the app, or the reverse. The audit then covers the part we take over and the points where it meets the rest, because most takeover surprises live at those boundaries. We agree with your team who owns each side of the API, so a change on one side never breaks the other unannounced.
A link to the app, the repositories if you hold them, what the previous team left and what worries you most. An engineer replies with the first step, which is often a list of what to collect before anything else.
Want to see how we work first? Read how a project runs or browse what we have built.
