Taking over an abandoned mobile app starts with an audit

Short answer

To take over an abandoned mobile app, first obtain the source repository, backend access and developer accounts. Then audit the product before requesting a fixed recovery quote. The brief proposes five to ten days for this work and an indicative €3,000 to €5,000 excluding VAT budget. The report should compare retaining usable code with rebuilding weak parts. A fixed quote issued before anyone reads the project rests on unknowns. If the repository is unavailable, the first assignment is to recover the product's assets, not promise a launch date.

A stalled project is not always lost code

A provider may leave behind a sound application with a poor handover. Elsewhere, screens look almost finished while sign-in, data handling or store publication was never completed. Visual progress tells you little about the remaining work. A demo video cannot replace a reproducible build or access to the environments.

Start with a short history: who developed what, which build was tested on a real phone, which bugs are known, and what has already been paid? Collect the deliverables listed in the contract. The first obstacle is often administrative: a Git repository owned by the former provider, a database in their account, or unknown signing credentials. Our guide to mobile app source code ownership gives the questions to ask.

"The code exists" and "the business can maintain it" are separate claims. Without services access and a way to produce another release, the repository is not enough. A thinly documented app can still be recoverable if it builds, the data is intact and the main journey works.

Eight checks in a useful audit

An audit should produce evidence rather than a broad rating. It begins with access: repository, history, branches, licences and client ownership of accounts. Next, can a new developer install the project and make a build from written instructions?

The remaining checks cover the stack and dependencies, backend and data, code quality, tests, security, and publication. Ask for a finding, its impact and a proposed action for each. "Old dependencies" is too vague; identify which ones block an upgrade or release. "No tests" is not a final verdict if the critical journey can be covered before work continues.

Check	Evidence to request
Access	Repository and accounts visible to the product owner
Documentation	Reproducible installation and build
Stack	Versions, risky packages and upgrade effort
Backend	Schema, backups, APIs and permissions
Code	Traceable business journeys and understandable components
Tests	Existing coverage and what needs coverage before launch
Security	Reviewed secrets, authentication and access rights
Stores	Identifiers, signing and ability to ship an update

A screenshot does not prove the app still builds. The auditor should run it, follow a complete journey and record every missing prerequisite. Mobile app scoping then turns those findings into a recovery scope.

Repair or rebuild: make an economic decision

Past spending is not the deciding factor; that money will not return. Compare the remaining cost of a publishable app with a focused rebuild, including maintenance risk after launch. A clean database and readable backend can be worth retaining even if the mobile client needs replacing. A Care plan (€290, €590 or €1,190 per month depending on the level) then takes over OS updates, fixes and continuous supervision.

I would keep code when the core journey works, the project builds, dependencies remain supported and the product owner controls access. I would recommend a focused rebuild when every fix breaks another area, secrets are scattered, or nobody can explain the data. The report must say which modules survive, which go, and why.

Do not accept a false choice between keeping everything and throwing everything away. The data model and stable integrations can often stay while screens and sign-in are rebuilt. Both estimates should use the same functional scope. Otherwise, a "start again" recommendation may mainly reflect the new provider's preference.

Store accounts can change the plan

A published app has a listing, reviews, an identifier and possibly subscriptions. Find out who owns the developer account before promising a simple update. Apple's official transfer process preserves availability, ratings and reviews. Google also documents app transfers between developer accounts. Eligibility and setup still need checking for the specific product.

If the original account is inaccessible, a new listing may be necessary. That changes timing, user communication and sometimes subscription continuity. An audit therefore needs to cover signing, app identifiers, payment accounts and push notification credentials. An unpublished app avoids some transfer issues, but still needs a client-owned account for its first release.

At Inyka, new project code goes into the client's repository from day one. For a takeover, the first aim is to regain that control: owner access, an inventory of secrets and a build process that no longer relies on the previous provider.

Ask for a price at the right point

The brief gives €3,000 to €5,000 excluding VAT as a planning range for a five to ten day audit. It is a comparison guide, not an advertised fixed Inyka price. A proposal should name the inspected scope, required access, checks actually run and report format. A project with no repository or services access may need an asset recovery assignment first.

After the report, ask for two estimates based on identical features: recover usable code and rebuild selected parts. Each must include tests, fixes, publication and handover. Our mobile app cost guide helps compare that total with a fresh development project.

A fixed price can make sense once the unknowns are removed. Before the audit, a bounded diagnostic assignment is more honest than an all-purpose "rescue" package filled with exclusions. No provider can know how many days remain in a project they have not opened.

What Inyka can take on

Inyka works on React Native and Expo mobile apps, their backend and a dashboard attached to the app. The first phase checks source, data and publication. Where part of the app needs a rebuild, a fixed quote can follow once its scope is clear. The repository and access belong with the product owner.

We do not sell a full takeover of a complex native Swift iOS application or systems requiring certified medical, banking or insurance capabilities. A limited diagnostic may still document a problem, but it is not a promise to develop outside our scope.

The report should remain useful if the founder selects another provider. It needs verifiable findings, risks, priority actions and the economic comparison. That makes it an audit rather than a disguised sales step.

Five mistakes before a takeover begins

Paying for a rebuild before recovering access. The new studio cannot publish an update or inspect the backend. First request the contractual handover of repositories, accounts and data, then record anything still unavailable.

Equating age with unusable code. An older dependency may be upgraded without rebuilding the app. Conversely, a recent repository can hide a brittle payment flow. The audit should estimate repair effort against complete user journeys.

Testing only the home screen. Problems tend to surface in account recovery, synchronization and failed payments. Require at least one complete journey from a clean installation through the product's main action.

Making documentation the whole verdict. A missing README slows a takeover but does not automatically make code unsound. Have the auditor reproduce a build and inspect data, then price the documentation work separately.

Leaving security until after release. Keys committed to the repository or shared accounts remain a risk even when the interface works. Plan credential rotation and assign an owner to each secret before shipping again.

What Inyka declines on an abandoned project

• A fixed quote to recover the entire product after only a demo. A demo shows apparent progress, not the state of source, data and accounts.
• An unbounded assignment with no diagnostic deliverable. An audit should end with a report and a decision, even when the recommendation is to rebuild.
• Keeping every line of code previously paid for just to justify the old budget. Past spending does not make the remaining code valuable.
• A complete takeover of complex pure native software or a product within Inyka's regulated exclusions. The React Native mobile scope must be explicit.

Handover checklist for the former provider

The founder can prepare a recovery pack before choosing an auditor. Request a written answer for each item:

1. Git repository address, administrator rights and release branches.
2. Latest installable build and version actually submitted to the stores.
3. External services list, with the owner of each account.
4. Setup instructions for development, staging and production.
5. Database schema, recent backup and restoration procedure.
6. Secret locations, certificates and signing keys, passed through a secure channel.
7. Known bugs and features left unfinished.
8. Apple and Google developer access or an initiated transfer process.
9. Billing, subscription and in-app purchase records when relevant.
10. Invoices, contracts and ownership or licence terms for components.

Record a missing item rather than replacing it with an assumption. A source archive without commit history, for instance, may still build but hides the reasons behind earlier changes. The report should distinguish verified facts, reasonable hypotheses and questions it cannot resolve. Ask the auditor to say what each missing item changes in the price estimate: a forgotten README affects onboarding, while a missing signing key may alter publication itself.

Keep a copy of the handover outside the former provider's workspace. Confirm that the product owner can sign in independently, invite another administrator and download a backup. A password sent by email is not the same as ownership of the account. Where the provider cannot transfer an asset, request a written explanation and an export in the format available. That record gives the auditor a clear boundary for the work and prevents a recovery quote from assuming access that does not exist.

Ask the auditor to attach the commands or steps used to reproduce the build. A later team should be able to repeat the check without relying on the auditor's memory. This small piece of evidence makes the report useful beyond the sales decision.

FAQ

Can someone audit an app without source access? They can review the visible product and contracts, but cannot credibly assess code quality. Recover the repository first or record in writing that it is unavailable.

Does the auditor have to build the replacement? No. Ask for a portable report and a list of client-owned accounts. Another studio should be able to review the evidence and challenge the recommendation.

How long does the repair versus rebuild decision take? The brief allows five to ten days for an audit once access is ready. Recovering missing accounts or secrets can extend that schedule.

What about accounts still held by the former provider? List each account and authorized person, then request an official transfer or delegated access. Once control is restored, rotate secrets that were shared more widely than needed.

Must we pay again for features already built? Only if they need fixing or rebuilding. The report should separate retained work from new work without using the original spend to justify either.

Must the audit report include a detailed quote? It should at least give the options, assumptions and priority work. A firm quote follows when the chosen scope and access are clear.

What about data in an app that people still use? Begin with a controlled copy and document a backup. Production changes need an owner, a time window and a rollback procedure.

Can we change provider while the former contract is still open? That depends on the signed terms. Gather the contract, deliverables and access records for legal advice if needed; the new studio should not decide a contractual dispute.

Get the project read before signing

If your app is stalled, collect the repository, account access and latest build, then bring the project to Inyka to scope an audit. The first decision worth paying for is what to keep, not an unsupported launch promise.

Book a 30-minute discovery call to review the assets available and the access still missing.