Walsh Costigan Let's chat

Fixing & maintaining an app

App Rescue: What to Do When Your Developer Leaves (or Your App Is Falling Apart)

By · · 4 min read

Short answer: First, secure every account: Apple, Google, the code repository, backend, subscriptions, domain and email. Then have an experienced developer audit the code, crash reports and subscription setup before changing anything. Stabilise first: fix crashes, purchase bugs and build issues. Only then decide whether to keep improving the existing code or rebuild. Most apps can be rescued without a full rewrite.

Over the years I've picked up plenty of codebases other people started, both as a contractor and as a senior developer. The panic usually sounds like: "My developer stopped responding," "The agency wants $X to keep going," or "Every update breaks something." Here's the calm way through it.

Step 1: Secure your accounts (today)

Before anything technical, make sure you control:

  • Apple Developer account (you should be Account Holder, not just Admin)
  • Google Play Console (owner)
  • Code repository (GitHub, GitLab, Bitbucket), with admin access, not just read
  • Backend and hosting (Firebase, Supabase, AWS, Heroku and so on)
  • Subscription tools (RevenueCat, Stripe)
  • Domain and DNS, plus the email addresses used for these accounts
  • Analytics, crash reporting and push certificates or keys
  • Design files (Figma)

If the developer holds any of these, request transfer in writing. If the app was published under their developer account, moving it requires an app transfer, which both parties must complete. Start that now.

Step 2: Get the code building

The first technical milestone is boring and essential: can a new developer build and run the app from the repo? You'd be surprised how often the answer is no, because of missing environment variables, private keys on someone's laptop, or outdated dependencies.

Step 3: Audit before you change anything

A good audit covers:

  • Crash rate and top crashes (Crashlytics or Sentry). Is the app stable?
  • Subscription integrity. Do purchases, restores, renewals and cross-platform logins work? Broken purchase flows quietly cost money every day.
  • Dependency health. How far behind are React Native/Expo, SDKs and libraries? Is the app at risk of falling below Apple's or Google's minimum SDK requirements?
  • Code quality. Is it organised, typed and tested, or one 5,000-line file?
  • Security. API keys in the app bundle, open database rules, unsecured endpoints.
  • Data model. Can it support where the product is going?
  • Analytics. Is the funnel tracked at all?

You should get back a written report covering what's broken, what's risky, what's fine, and an estimate for each fix.

Step 4: Stabilise

Fix in this order:

  1. Anything losing money: purchase bugs, broken paywalls, sign-in failures
  2. Crashes affecting many users
  3. Store compliance: SDK target levels, privacy manifests, account deletion
  4. Build and deploy pipeline: reliable builds and, ideally, over-the-air updates

Only after this should new features start.

Step 5: Fix or rebuild?

The urge to rewrite is strong. It's often wrong. Here's how I decide:

Keep and improve the existing code if:

  • It's on a mainstream stack (React Native, Swift, Kotlin, Flutter)
  • The core data model is sound
  • Problems are local, like messy screens or missing tests

Rebuild if:

  • It's on an abandoned framework, or a no-code or white-label tool you can't extend
  • The data model fundamentally can't support the product
  • Fixing would cost more than rebuilding, which happens but less often than people think

A middle path is often best: rebuild piece by piece, replacing one area at a time while the app stays live.

How do I avoid losing subscribers during a rescue?

If the app has paying users, protect them:

  • Keep the same bundle ID and listing so updates reach existing users and subscriptions continue.
  • Test purchase restoration and renewal on real devices before every release.
  • Use staged rollouts on both stores so a bad release only reaches a small percentage of users.

How do I prevent the next rescue?

  • You own all accounts, always.
  • Code is in your repository.
  • Mainstream stack and documented build steps.
  • A clear support agreement after launch.

See how to hire an app developer for what to set up from day one.

FAQ

Can a new developer take over an app built by someone else?

Yes, if you have the source code and access to the accounts. Mainstream stacks like React Native are especially easy to hand over.

What if my old developer won't give me the code?

Check your contract for IP and ownership clauses. If you paid for the work, you usually have a strong claim. In the meantime, secure every account you can. Without the code, a rebuild may be faster than a dispute.

How much does an app rescue cost?

An initial audit is usually a small, fixed-scope engagement. Stabilisation depends on what the audit finds. It typically costs much less than a rebuild.

Should I rewrite my app from scratch?

Usually not as a first move. Stabilise, measure, then decide. Full rewrites take longer than planned and freeze growth in the meantime.

My app was built on a white-label platform. Can it be rescued?

The content and users can be moved, but the code usually can't. This is effectively a migration to a custom app.

Keep reading