Short answer. Most apps that feel broken need rework, not a rewrite. Rewrite in only three cases: you can't build the app from its code, the signing key and accounts are gone, or the product is changing so much that most screens change anyway. Before you pay for either, get an audit that answers three questions. Can we build it? Who holds the keys? Where do the problems cluster? Below are nine signs, the decision table we use, and a ten-area checklist you can run yourself.
The 9 signs
Each sign links to the rule or threshold behind it, so you can check your own app today.
| # | What you see | Why it matters |
|---|---|---|
| 1 | Releases are rare, manual and nerve-racking. One person knows how to build it. Weeks pass between releases. | Every store deadline becomes a crisis. Fixes wait for "the next release". |
| 2 | Crash or ANR rates near Google's line. In Android vitals, the user-perceived crash rate is close to 1.09%, or the ANR rate (the app froze) close to 0.47%. Or either passes 8% on one phone model. | Above those lines, Google Play may reduce your app's visibility and show a warning on your store listing. From February 2027, the same can apply to apps over Play's memory and code-optimisation thresholds. |
| 3 | A store deadline turned into a project. Moving to target API 36 (required since 31 Aug 2026) or Play Billing Library 8 (same date) takes weeks, not days. So does support for 16 KB memory pages (updates blocked from 1 Feb 2027). Or you can't build with Xcode 26, required for uploads since 28 Apr 2026. | These are routine updates that every live app has to make. When one takes weeks, the libraries underneath are usually years out of date. |
| 4 | You don't hold the keys. The code sits in the old developer's account. Nobody knows where the signing key is. The app is published from someone else's Play Console or Apple account. | Without Play App Signing, a lost key means "you will not be able to publish updates to your existing app". |
| 5 | The team went quiet, or left. Replies take weeks. Nobody else can explain how the code works. | You can't estimate or change what nobody understands. One UK agency that sells app rescue says roughly half of its rescue enquiries involve an offshore team that stopped communicating. The other half involve a developer or agency that isn't around any more. That is one agency's experience (as published on 23 Sep 2026), not a survey. |
| 6 | Small changes break unrelated screens. A fix in one place creates a bug in another. There are no automated tests on sign-in, payments or the core flow, or the tests never fail. | Without trustworthy tests, every change is a gamble. |
| 7 | Nobody dares upgrade the SDKs. The third-party libraries (SDKs) for payments, push, analytics and ads are years old, because "upgrading breaks the build". | Store rules name versions: Billing Library 8 on Google Play; on the App Store, declared reasons for certain APIs, including inside third-party SDKs, since 1 May 2024. |
| 8 | You can't vouch for how it handles personal data. Tokens or personal data may sit unencrypted on the phone. Nobody knows what each SDK collects. | The OWASP MASVS groups mobile security checks into eight areas: storage, crypto, authentication, network, platform, code, resilience and privacy. |
| 9 | iOS and Android drift apart, and every estimate grows. The same feature behaves differently on each platform. A small change takes weeks. | The structure of the code fights every change, and each change costs more than the last. |
How to read it. Check sign 4 first: who holds the keys decides what is possible. The more of the other signs you recognise, the more an outside look is worth before you pay for new features.
Rework or rewrite: the decision table
We start from rework. A rewrite throws away every bug fix and edge case the old code learned the hard way, and testing starts again from zero. If the app already works and your team knows it, improving it is almost always cheaper, whatever it is built with.
| The audit finds | Points to rework | Points to rewrite |
|---|---|---|
| Build | It builds from the repo on a clean machine | The code is missing or can't be built, and can't be recovered |
| Keys and accounts | You hold the signing key, or Play App Signing is on; the store accounts are yours | The signing key is lost without Play App Signing: you need a new listing anyway |
| Technology | A supported language and framework; dependencies can move up step by step | The framework is abandoned, or several major versions behind with no upgrade path |
| Where the problems are | A few areas: crashes, payments, one heavy screen | Everywhere: data, navigation and state are tangled across the app |
| The product | The same product, made better | Most screens change anyway because the product is changing |
| Cost | The rework estimate is clearly below a rebuild | The rework estimate is close to the cost of a rebuild |
A rebuild costs roughly what a new app costs. Our cost calculator puts a mid-size business app, one shared codebase, standard design, at £58,500–£79,000. That is about 1,500 hours of work (1,524 in the calculator's model). Price your own rebuild there, and ask for the rework estimate in hours too, so you compare like with like.
One more rule: a rewrite doesn't fix a process. If releases were manual and nothing was tested, a new codebase with the same habits ends up in the same place. Fix the pipeline and the tests either way.
Check the keys first
Sign 4 decides what is possible, so check it before anything else:
- The code repository is in your company's organisation, not a developer's personal account.
- The Android signing key is yours, or Play App Signing is on. Then a lost upload key can be reset.
- The Google Play and Apple developer accounts are in your company's name.
- Backend hosting, domains, push, analytics and payment accounts are in your company's name too.
If the app sits in someone else's store account, it can move to yours. But the current owner has to start the transfer:
- Google Play. The current owner starts it and your account approves it. Users, statistics, ratings, reviews and subscriptions move with the app. Sales, earnings and bulk-export reports stay behind, and test groups have to be set up again. Google says its support team replies to transfer requests within 2 business days.
- App Store. The sending Account Holder starts it, and the receiving one accepts. The app keeps its reviews and ratings, and users keep getting updates. It must meet all of Apple's transfer criteria first.
To receive the app, your company needs its own organisation developer account. Both Google and Apple ask for a D-U-N-S number to open one. Google warns that getting a number "can take up to 30 days", so start there.
Both transfers need the old owner to act. Ask while they still answer your emails.
What an audit checks
Use this list on any audit proposal, ours included. If a proposal skips an area, ask why.
| Area | What we look at | Red flag |
|---|---|---|
| 1. Access and ownership | Repo, signing keys and Play App Signing, Play Console and App Store Connect roles, backend hosting, domains, push, analytics and payment accounts | Anything held only by a person who has left |
| 2. Build | A clean build from the repo, CI setup, how secrets are stored | It only builds on one laptop |
| 3. Release | Every step from merge to store, how long it takes, who approves | Manual steps with no owner |
| 4. Stability | Android vitals, crash and ANR reports, memory use, the phone models where problems cluster | Above Google Play's thresholds |
| 5. Store compliance | Target API level, Billing Library version, 16 KB support, Xcode and SDK version, privacy declarations | A deadline already passed |
| 6. Dependencies | The age of each SDK and library, known vulnerabilities, abandoned packages | A core library no longer maintained |
| 7. Architecture and code | How the app is layered, where business logic lives, duplication between iOS and Android, the riskiest modules | Business logic spread through the screens |
| 8. Tests | What is covered, whether tests run in CI and on real devices | Tests that don't run, or can't fail |
| 9. Security and privacy | The MASVS areas: storage, network, authentication; what each SDK collects | Personal data in plain text on the device |
| 10. Backend contract | API documentation, versioning, what happens to old app versions when the server changes | A server change breaks the app in the store |
What you should get at the end: a written list of findings, ranked by risk. A clear call on rework or rewrite, with a rough estimate for both. A plan for the first two weeks.
Our version. Our free high-level audit is a first look, not all ten areas. From your store links, we read what users complain about in your reviews and check store compliance (area 5). If you give us read access to Play Console, App Store Connect or your crash tool, we add stability (area 4). We don't need your code for it. A 20-minute walkthrough follows, and you keep the plan of what to fix first. The other areas get checked once a team, us or another, starts work on the code.
What audits cost: published prices
Prices as each provider published them on its own page on 23 September 2026. Compare what each one buys, not just the price.
| Offer | Price | What it buys | Source |
|---|---|---|---|
| Foresight Mobile (UK): app rescue review | Free check, then £95 | A person answers the free check in writing. The £95 review is time-boxed: architecture, security, stability and crash health, whether the app can be saved, and who owns the code and accounts. Written report. The £95 is credited in full against any paid work that follows. | foresightmobile.com, as published on 23 Sep 2026 |
| Foresight Mobile (UK): App Gameplan | £3,500 | A separate four-week discovery plan: summary, prototype, fixed-cost quote, roadmap and architecture plan. Not a code audit. Credited against the first development sprint. | foresightmobile.com, as published on 23 Sep 2026 |
| Lickability (US) | $1,750 / $2,500 | Code audit: 1 day of work for up to 25,000 lines; 1–2 days for up to 50,000 | appaudit.net, as published on 23 Sep 2026 |
| LeanCode (Poland): Basic Audit | €6,400 | Up to 2 weeks, for smaller codebases; executive summary with key findings | leancode.co, as published on 23 Sep 2026 |
| LeanCode (Poland): Full or Security Code Audit | from €11,900 | 4–6 weeks, for large apps (100k+ lines); executive summary and full report | leancode.co, as published on 23 Sep 2026 |
| Next Era Solutions: free high-level audit | Free | A first look from outside the code: the complaints in your store reviews, the store rules your next update has to meet and, with read access, crash and ANR rates. A 20-minute walkthrough and a plan you keep. Not a code audit. |
Three different products share the word "audit". Match the one you buy to your signs:
| Your situation | What fits | Published example |
|---|---|---|
| You need to know whether the app can be saved, and who owns the code and accounts (signs 4 and 5) | A short, time-boxed review | Foresight's £95 review |
| Several signs, in an app of up to about 50,000 lines of code | A one-to-two-day code audit with a written report | Lickability's two tiers |
| A large app (100,000+ lines), or one with high industry-specific risk (sign 8) | A multi-week audit with a full report | LeanCode's full and security audits |
Whichever you buy, check it against the ten areas above.
Where we have worked inside existing apps
We have not published a takeover story, so we don't call ourselves a rescue agency. We have joined live products several times, and our role differed each time. The closest to this post's subject is the POS work.
A stabilisation story: a POS platform that shops use every day
A B2B retail platform in the DACH region needed Android engineers to extend its POS system for food retail businesses, such as bakeries and grocers. The platform supported 500+ of them. The product was not handed over to us. Our Android engineers worked inside the client's core product team. For more than a year, our work covered feature delivery, stabilisation and ongoing support.
The app ran on specialised Android POS devices. It had to work with digital scales, receipt printers and barcode scanners. Several registers had to talk to each other over the shop's local network, and critical checkout steps had to keep working without internet. Our part included the hardware integration layers for those devices, and the cashier, checkout and device-management flows.
What it shows, and what it doesn't: it shows stabilisation work on a live product that businesses depend on. It doesn't show a takeover of an app another team abandoned, and we won't claim one until we can publish it. Read the Enterprise POS case.
Other products we joined
- MobileVision, a clinical app. We migrated the mobile CI/CD flow, with automated test runs and quality gates in front of each release candidate, and fixed the Flutter test automation suite, including its batch runs. Connecting the app to BrowserStack also turned up issues in the client's own automation tests, as the client's review says. That is sign 6 from the other side: the tests themselves needed fixing. Read the case.
- Automotive radio (NDA). A large international carmaker brought in Android engineers to strengthen the radio module of its next-generation infotainment system. Over 6 months, we worked with embedded-device and automotive teams to stabilise hardware integration and playback. Read the case.
- Red Robin and Dutch Bros. A developer from our team joined each client's existing product team and codebase, working in their processes. Red Robin · Dutch Bros.
"What if our last team went silent?"
It's a fair question to ask any outside team, including a remote one like ours. Ask for these in writing, whoever you hire:
- The repo is yours. It lives in your organisation, or, if the team keeps it on their side at first to move faster, the contract says when it moves to you.
- Store accounts end up in your company's name, with the team invited as users. If the app starts under the team's account, get the transfer date in writing.
- Play App Signing is on, so a lost upload key can be reset.
- You see progress every week, against the plan. We report weekly.
- Your contract is with a company you can hold to it. Ours is registered in Estonia, in the EU; the legal entity and registry code are in the site footer.
- A handover document is kept up to date, not written on the last day.
With us, where the repo and store accounts sit at the start depends on the agreement. Both ways happen: sometimes they are yours from day one; on some MVPs they sit on our side at first so we can move faster, then transfer to you. The contract says which, and when.
If a vendor can't agree to 1–3, walk away. That includes us.
Next step
- Get a first look, free. Our free high-level audit starts from your store links: the complaints in your reviews, the store rules your next update has to meet and, with read access, crash and ANR rates. A 20-minute walkthrough follows, and you keep the plan. For the other areas, use the checklist above with whichever team you hire.
- Not sure an audit is the right first step? Book a 30-min call (below). Bring a screenshot of your Android vitals or crash report, a list of the SDKs you use, and who holds the signing key and store accounts. We'll tell you which of the ten areas we'd check first.
- Rebuilding anyway? Price it first in the cost calculator.
- Check every current store deadline: App store and platform rules in force for 2026–27.