App Rescue: We Take Over Your Existing App
Your developer stopped replying, or left, or delivered something that does not work. You have an app, possibly a repository, possibly no idea what state either is in. The first job is to find out, before anyone promises you anything.
Discuss your projectSigns you need this
Any one of these is enough. Several together usually means the project has been drifting for longer than anyone has admitted.
- Your developer has gone quiet, or has been promising "nearly done" for several months.
- You cannot get a build to install on a device without the previous developer running it for you.
- The App Store or Play listing is under someone else's account, or you do not know whose account it is under.
- Nobody can tell you where the source code is, or the repository you were given will not build.
- The app works in a demo and fails on real data or a real connection.
- An OS update broke it and there is nobody to fix it.
- A store deadline — a target API level, a privacy declaration — is approaching and no one is handling it.
- You are paying a monthly retainer and cannot name what changed last month.
How it works
- 01
Audit, before any promise
A fixed-scope week or so establishing what exists: does it build from a clean checkout, what is in the dependency tree, how far behind the framework and OS targets are, whether there are tests, where credentials are stored, and what the data model looks like. You get a written report and a frank assessment. If the honest answer is that it should be rebuilt, the report says so and explains why in terms you can check.
- 02
Secure what you own
Often more urgent than any code. Store accounts transferred into your company's name, signing keys and certificates recovered or regenerated, repository ownership moved to you, cloud and third-party accounts reissued under your billing, and the previous developer's access revoked. People put this off and it is the step that is painful to do later.
- 03
Stabilise
Before new features: get it building reproducibly, get a release out through a pipeline, fix the crashes that affect the most users, and deal with any imminent store deadline. The aim is an app that can be shipped at all, which is a precondition for everything else.
- 04
Then plan forward
With the real state known, we agree what comes next — continue, refactor the parts that are blocking progress, or rebuild a layer. That decision belongs to you and it should be made with the audit in hand, not from a sales conversation.
Fix, refactor, or rebuild
A rebuild is the most profitable recommendation an agency can make, which is exactly why you should want the reasoning in writing. These are the conditions under which we recommend each.
| When we recommend it | What it means for you | |
|---|---|---|
| Fix in place | It builds, the architecture is sound, the problems are specific defects or neglect | Fastest and cheapest. Most audits end here, more often than clients expect |
| Refactor one layer | The app is largely fine but one area — networking, persistence, authentication — blocks every change | A contained piece of work with a visible payoff, then normal development resumes |
| Rebuild | Framework or dependencies are abandoned, no source exists, or the data model is wrong in a way that touches everything | A real project. We would reuse the backend, API and design where they are sound, so it is rarely a rebuild of everything |
We will give you the reasoning in writing either way, so a second opinion is cheap to get. On an app we did not build, we would rather be checked.
Common questions
Go deeper
Tell us what you need
Describe the problem and we will come back with scope, timeline, and a rate. No obligation to proceed.
Get in touch