Failed app rebuild: what to do now?
By Nathan Guigui, Founder of GUIGUI Tech · Facts checked against the official sources listed at the end of the article
When an app rebuild has failed (blown budget, unstable app, store rejections, a developer who no longer answers), you should neither restart development right away nor give up on the app. The right sequence has three steps: recover access and the code, have the app audited by an independent third party, then decide whether to save it, partly rebuild it or rebuild it entirely. The first 48 hours are mostly about securing what belongs to you.
How do you tell which situation your app is in?
A failed app rebuild shows itself through symptoms, and each symptom calls for a different first move.
| What you are seeing | What it often means | First move |
|---|---|---|
| Budget overrun, delivery keeps slipping | Underestimated scope, technical debt | Freeze new requests, get an inventory of what was delivered |
| The app crashes, lags or loses data | Weak quality, testing or architecture | Measure the crashes, protect the data |
| Apple or Google blocks your updates | Non-compliance with store rules | Read the rejection message carefully |
| The developer no longer answers | Risk of losing the code and accounts | Recover access as a top priority |
| Nobody dares touch the code | Unreadable code, no tests or documentation | Audit before any new feature |
| A migration was left half-done | Unstable intermediate version | Establish what actually runs in production |
Several rows often apply at once. For store blocks, see the Google Play target API level block and Apple rejection under guideline 4.2.
What should you do in the first 48 hours after a failed project?
In the first 48 hours, the goal is not to fix the app but to regain control: make sure every critical access is in your name. As long as the code or the accounts depend on a single outside person, every decision stays fragile.
| Access | How to check it is yours |
|---|---|
| Source code repository (GitHub, GitLab…) | You can see the full history with your own login |
| Apple Developer and Google Play Console accounts | You are the account holder, with your own login |
| Android signing key | Managed by Google (Play App Signing) or in your possession |
| Domain names, hosting, database | Accounts in your name, invoices sent to you |
| Third-party services (payments, email, notifications) | Every account and every key is listed |
| Contracts, quotes, specifications | You have the signed versions |
The source code
The source code is the text that makes your app work: without it, no fix and no update is possible. Ask for owner access to the repository rather than a zip file, because the history helps you understand what was done. On GitHub, according to the official documentation, transferring a repository keeps its history, issues and pull requests.
The App Store and Google Play accounts
At Apple, the account holder, called the Account Holder, is according to Apple’s documentation the person who renews the membership and accepts legal agreements on behalf of the organization. If that is your former developer, they control your app.
If the app was published on the developer’s account, a transfer is possible, but it requires their cooperation. According to App Store Connect Help, the original Account Holder initiates the transfer, the receiving Account Holder accepts it, and the app keeps its ratings and reviews. At Google, according to Play Console Help, the original account owner submits the request, the target account approves it, and users, ratings and reviews move with the app.
The Android signing key
An Android app is signed with a digital key that proves to Google an update really comes from you. According to Play Console Help, with Play App Signing, Google can reset a lost upload key; a self-managed app signing key that has been lost, however, cannot be reset. Without Play App Signing, recovering that file and its password is urgent.
Domains, servers and third-party services
A domain registered to your developer or a server paid with their card can take your app offline overnight. Also ask for the list of API keys (the codes that let the app talk to a service): they often live outside the repository.
Contracts and code ownership
Paying for an app does not mean you own the rights to it, at least under French law. According to Bpifrance Création, without an explicit assignment agreement the contractor remains the owner of the delivered code. Article L131-3 of the French Intellectual Property Code requires each assigned right to be stated separately and its scope delimited; the automatic ownership set out in article L113-9 only covers employees. Look for the assignment clause in your contract and, if it is missing or vague, talk to a lawyer before committing to major work on that code. Other countries have different rules, and this article is not legal advice.
Key point
Ask for access in writing, as a factual list and without blame. A developer in difficulty cooperates more easily when the request is clear and limited to what is yours. Keep a record of every exchange.
What if the developer has abandoned the app?
Taking over an app abandoned by its developer is possible in most cases, provided you first recover the source code and the publishing accounts. Without the source code, the app can no longer be updated: you either obtain it or start a new app.
If the accounts are yours but the code is missing, the situation is serious but manageable; if everything sits with the developer, it becomes partly a legal matter. Once the code is back, the real test is simple: a new developer must be able to build and publish the app from their own machine.
Why get an independent audit before spending more?
An independent audit before any new spending keeps you from funding the project again without knowing what is wrong. Without reading the code, no provider can seriously estimate a takeover.
A recovery audit, also called an emergency audit, separates facts from impressions: it tells you what works, what is fragile and what is missing, and gives you a common basis to compare proposals. Insist on a report that any team can use. In my experience as a practitioner, a few days of audit cost far less than a few weeks of development in the wrong direction.
What does an app recovery audit check?
A recovery audit checks that you can take the app back in hand, measures its actual state and puts a price on the options. It usually covers:
- Access: is everything available and in your name?
- Publishing: can the app be built and sent to the stores from the repository?
- Versions and dependencies: are the framework (React Native, Expo, Capacitor…) and libraries maintained and compatible with current Apple and Google requirements?
- Stability: which screens crash, on which devices?
- Security: are secret keys exposed, is user data protected?
- Readability, tests and documentation: can a new developer change the code without breaking everything?
The deliverable should be readable by a non-technical person: a summary, risks ranked by priority and a costed recommendation. That is the scope of our App Rescue Audit, at €1,500 excl. VAT in 5 business days.
How do you recognize a badly built app?
A badly built app shows itself through its effects: every fix causes another problem and nobody can explain simply how it works. The warning signs:
- a small change always takes several days;
- the same bugs come back after being “fixed”;
- only one developer knows how to publish the app;
- the app runs on old versions nobody dares to upgrade.
Taken together, these signs mean that technical debt, the pile of shortcuts that must be paid back later, is already slowing your product down. For a fuller diagnosis, see 10 signs your mobile app is badly built.
Should you save the app or rebuild it?
Choosing between saving, partly rebuilding or fully rebuilding an app depends on the actual state of the code, what you managed to recover and the gap with your needs. It should be decided after the audit, never on a hunch.
| Option | When it makes sense | What you have to accept |
|---|---|---|
| Save | Code recovered, buildable, sound foundation despite localized flaws | A prioritized fix plan |
| Partly rebuild | One part is solid (server, data), another needs redoing (mobile app, a module) | Running old and new side by side during the transition |
| Fully rebuild | Code missing, abandoned technology, or a foundation that is too fragile | A full project, with specifications and data migration |
Rebuilding is not always the safest route: a rebuild has to rediscover every business rule of the old app, which is often undocumented. We cover the decision criteria in Rebuild your app from scratch or save it?
What should you do after a failed app migration?
After a failed migration, the first question is which version actually runs in production and whether you can still update it. The most common cases:
- A React Native or Expo upgrade left halfway, often around the switch to the New Architecture, now mandatory.
- An unfinished Cordova or Ionic to Capacitor migration, with plugins that were never replaced.
- An incomplete move off no-code, where business rules or data are missing (see our guide to leaving Bubble).
Keep the old version working until the new one is validated, and have the remaining path audited before restarting work. For React Native, our guide to a failed React Native migration sets out the recovery plan.
Getting help after a failed rebuild or migration
GUIGUI Tech’s App Rescue Audit is the recovery audit described above: €1,500 excl. VAT, delivered in 5 business days, for a React Native, Expo, Capacitor, Ionic or Cordova app, a React, Next.js or Vue.js web app, or code generated with Lovable or Bolt. It includes the access recovery checklist, a review of the code and architecture, a quick security check, the state of dependencies and store compliance, a verdict (save, partly rebuild or start over) with a costed and prioritized plan, a PDF report and a one-hour debrief call. It is deducted from the final price if you confirm the work within 30 days.
Depending on the verdict, next steps can be Google Play and App Store Compliance (from €2,500 excl. VAT, 1 to 3 weeks) if the emergency is a store block, an Expo SDK & New Architecture Upgrade (from €6,500 excl. VAT, 2 to 4 weeks) or a Full React Native Migration (from €18,000 excl. VAT, 4 to 8 weeks) for a React Native app stuck on an old version, or a migration to Capacitor (from €9,500 excl. VAT) for a Cordova or Ionic app. If your React Native app works and only needs a version upgrade, the React Native Migration Audit, at the same price, is enough. For a Bubble, Adalo or FlutterFlow app, the Move off no-code offer starts with a feasibility audit at €800 excl. VAT over 2 days.
Frequently asked questions
What should you do first when an app rebuild has failed?
What is an app recovery audit?
Do I own my app’s code if I paid for it?
Can you recover an app published on your former developer’s store account?
Do you have to rebuild an app from scratch after a failed rebuild?
How much does an audit cost after a failed app project?
Need help with this?
App Rescue Audit
Project gone off the rails, developer unreachable, unstable app or one generated with Lovable? We recover your access, audit the code and tell you whether to save it, partly rebuild it or start over.
Learn more →
Sources
- Overview of app transfer, App Store Connect Help (Apple Developer)
- Developer account roles, including Account Holder (Apple Developer)
- Transfer apps to a different developer account, Play Console Help (Google)
- Play App Signing and upload key reset, Play Console Help (Google)
- Article L131-3 of the French Intellectual Property Code, assignment of copyright (Légifrance, in French)
- Article L113-9 of the French Intellectual Property Code, software created by employees (Légifrance, in French)
- Legal protection of software (Bpifrance Création, in French)
- Transferring a repository (GitHub Docs)
