Taking Over a Failed Mobile App: What We Check First

There is a category of project nobody talks about on agency websites, because it does not make anyone dream: apps that already exist, that cost money, and that nobody wants to open anymore.

It is nonetheless a large share of what lands on our desk. A business owner paid, the app is live, it half works, and the person who built it has stopped replying. The question is no longer “how do I get an app built”, it has become “what do I do with this one”.

The method below is the one we apply before committing to anything. It is reproducible, and you can put most of it to any supplier you are talking to.

The four ways an app ends up abandoned

They do not share the same prognosis, and that is the first thing to establish.

The contractor disappeared

A badly negotiated end of contract, a liquidated company, a freelancer who changed careers. The code exists somewhere, but the access, the accounts and the keys are scattered. It is the most frequent case and, paradoxically, the most fixable: the problem is administrative before it is technical.

The in-house developer left

One person knew the project, nothing was documented, and the app still runs on services whose passwords nobody has. The risk here is called expiry: a certificate lapses, a key rotates, and the app stops dead.

The no-code prototype hit its ceiling

It did real work for two years. Then user numbers grew, performance collapsed, and the feature being asked for is not possible in the tool. The code is not salvageable, but the data and the business rules are, and they are often worth more than the code.

The app was delivered and then never maintained

It worked the day it was published. Two years later it crashes on recent OS versions, it will be rejected at the next update, and its rating has dropped. The code may well be fine. It is the process that never existed.

Before the code: who owns what

This is the step everybody skips, and the one that blocks the most projects. A technically simple takeover can be impossible for six months because an account is in the name of a company that no longer exists.

Do the inventory before anything else. Seven items, and for each of them the only good answer is “in my company’s name, and I have the access”.

Item	Why it blocks you if you do not have it
The App Store Connect account	Without it, no update is possible. Transferring an app between Apple accounts requires the active cooperation of the current holder
The Google Play Console account	Same logic. The transfer costs money and requires both parties
The Android signing certificate	The most dangerous one. Lose that file and you can never update the existing app again. You have to republish under a different identifier and start again from zero users
The company DUNS number	Required for an organisation developer account
The code repository, with its history	Code delivered as an archive, with no history, is code nobody can understand or take over cleanly
The back-end project (database, server, hosting)	Often created on the contractor’s personal account. It needs migrating, and that takes preparation
The third-party service keys (payment, maps, email sending, notifications)	A key you do not control is a scheduled outage

The Android signing certificate deserves a pause, because it is the only line in that table that is irreversible. If the contractor lost it and signing was not entrusted to Google, the published app is permanently frozen. You have to republish a new one, under a new identifier, and ask every user to reinstall. The cost sits in the user base you do not get back, not in the development.

That is the first question to ask, before you even find out whether the code is any good.

What we look at in the code, and what it reveals

A serious audit takes one to three days depending on the size of the project. It is not about reading all the code, it is about probing eight points that predict the rest.

1. Does it build. We pull the project, follow the procedure we were given, and try to produce an installable app. If nobody manages it in a day on a fresh machine, that is already the main finding: the project was not reproducible, therefore not maintainable.
2. The gap between the code and what is published. We compare the repository version with the version live on the stores. A gap of several versions means part of the actual work was never handed over.
3. The dependencies. We list the external libraries and when they were last updated. A library abandoned three years ago sitting on a critical path is debt that comes due at the next OS version.
4. Hardcoded secrets. API keys, passwords, access tokens written straight into the code. It is common, it is serious, and it gets fixed quickly. Mostly it tells you something about the level of rigour everywhere else.
5. The back-end security rules. The single most profitable test in the whole audit: can one user read another user’s data. On projects we take over, the answer is yes more often than you would imagine, and nobody had noticed.
6. Automated tests. How many matters less than whether any exist. Zero tests means every future change is a gamble, and that the cost of the smallest evolution carries a full manual verification phase on top.
7. Separation of layers. Is the business logic mixed into the display. When it is, you cannot change a screen without risking a business rule, and the takeover costs the price of a partial rewrite.
8. The real crash rate. The Apple and Google consoles publish it. A rate above 1% is visible to users and it explains the store rating all on its own.

Take over or rewrite: where the line sits

This is the heaviest decision, and it is not a matter of taste.

Look at the foundation first. If the general architecture is coherent, even imperfect, we take it over. Messy code, ugly screens, old dependencies, absent tests: all of that repairs, it is work. A data model that does not match the actual business does not. It is a foundation, and you do not straighten a foundation.

Look next at the nature of the tool. A no-code prototype that hit its ceiling cannot be taken over, since there is no code to take over. What is salvageable is the data, the business rules and above all two years of learning about what users actually need. That is a considerable asset, and it makes the rewrite far safer than a project starting from a blank page.

Look finally at the number of codebases. An app maintained in two separate versions, one iOS and one Android, costs twice as much to evolve, forever. When the takeover involves heavy work anyway, that is the moment to settle the question, rather than three years later.

A useful marker for the decision: when the estimated cost of the takeover exceeds half the cost of a rewrite, the rewrite is almost always the better purchase. You start with a known scope, real users, existing data and a list of defects already identified. It is the most comfortable situation there is for building an app.

The orders of magnitude for building new are covered in how much a mobile app costs in 2026.

The store rating, and why it does not get fixed in a day

Plenty of business owners assume that fixing the app will bring the rating back up. The mechanism works differently.

The displayed rating is a cumulative average. An app at 2.8 stars across 4,000 reviews does not climb to 4.2 because the fixed version is good: it takes a large volume of new positive reviews to move the average. Both stores have mechanisms to reset the rating on a major version change, but you have to steer them, they do not happen by accident.

What genuinely lifts a rating, in order: get the crash rate under 1%, reply publicly to the existing negative reviews, then ask for a review at the right moment, meaning right after the user got what they came for, never on app launch.

Count several months, and plan for it. A low rating costs downloads every day, and it is often the most quantifiable item in the whole file: multiply the daily lost revenue by the number of days already elapsed.

On the calendar side, a takeover shifts the first phase: recovering access comes before any code is written. The detail is in how long it takes to build a mobile app.

The list to send your former contractor

Copy and paste this message. It obtains in one go what otherwise takes three weeks to recover in small pieces, and its precision discourages evasive replies.

Hello,

As part of taking the project over, please send us the following:

1. Access to the code repository, including the full version history.
2. The exact procedure for producing an installable app from a fresh machine, and the tool versions used.
3. Transfer of ownership of the App Store Connect account and the Google Play Console account to our company, or failing that, administrator access.
4. The Android signing file and its password, or written confirmation that signing is delegated to Google Play.
5. Administrator access to the back-end project, the database and the hosting.
6. The list of third-party services used, with the account each one is attached to.
7. The credentials and API keys for the payment, notification and email sending services.
8. Any existing documentation, even partial.

Please confirm within eight days which items you are able to hand over and which you are not.

The last sentence is the one that counts. What the contractor cannot hand over tells you more than everything else, and you learn it before you sign with somebody new.

What the audit costs, and what skipping it costs

An audit is billed, and that is normal: it is engineering work, not sales preparation. It represents a fraction of the project, it is deducted from the package if the takeover goes ahead, and it gives you back a firm answer on what is salvageable, a number for each of the two options, and the precise list of missing access with how long it will take to obtain.

Without an audit, the next supplier has to price blind. Blind pricing on an existing project is always one of two things: padded to cover the unknown, or underestimated and renegotiated along the way. Both cost you more than the audit.

There is also a cost that appears on no accounting line. An abandoned app weighs on a team: nobody dares touch it anymore, every change request gets pushed back, and the subject becomes a permanent source of discomfort in meetings. Settling it, even with “we’re stopping”, beats letting it run.

Where to start

If you are in this situation, do these three things this week, before consulting anyone:

1. Check whose name your two store accounts are in. It is the only point that can cost you your user base.
2. Send the list above to your former contractor, with an eight-day deadline.
3. Write down what the situation costs you per month: lost downloads, time spent working around it, customers who do not come back. That number will decide the scope, not the state of the code.

After that, we can look at it together. The scoping questionnaire takes five minutes and prepares a 45-minute call. What we deliver is described on the mobile app page.

Frequently asked questions

Can an app be recovered when the contractor has disappeared?

In most cases yes, but the blocker is administrative before it is technical. Everything depends on who holds the App Store Connect account, the Google Play account and the Android signing certificate. The code itself is almost always found.

What happens if the Android signing certificate is lost?

That is the one point of no return. If signing was not delegated to Google Play, the published app can never be updated again. You have to publish a new one under a different identifier and ask every user to reinstall, so you restart from zero users.

Should you take over the existing code or rewrite everything?

Messy code, ugly screens, outdated dependencies and missing tests can all be repaired. A data model that does not match the real business cannot. When the estimated cost of taking over exceeds half the cost of a rewrite, the rewrite is almost always the better buy.

How do you raise the rating of a badly rated app?

First bring the crash rate below 1%, then answer the existing negative reviews publicly, then ask for a review right after the user has got what they came for. The rating is a cumulative average, so count several months.

Can a no-code app be migrated to a real app?

The code from a no-code tool is not salvageable, but the data, the business rules and everything learned about what users actually need are. That is an asset, and it makes a rewrite far safer than a project started from a blank page.

In short

• Establish who owns what first: store accounts, Android signing certificate, repository, back end, third-party keys. That is where the irreversible blockers live.
• A lost Android signing certificate is the only point of no return: it forces a republish and a restart from zero users.
• A one to three day audit answers the real question: take over or rewrite.
• What repairs is messy code. What does not repair is a data model that does not match the business.
• Past half the cost of a rewrite, taking over is no longer the right purchase.
• A low store rating recovers over several months, and only if the crash rate goes under 1%.