Taking Over an App From Another Developer

Q: Can I have my existing app taken over and developed further by another developer?

Yes, in the vast majority of cases. The prerequisites are access to the source code, to the store accounts and a usage right that permits modification. With an honest assessment first, you can reliably clarify whether the app will be stabilised and expanded or whether a rebuild is cheaper.

Q: Is it worth saving the app, or is a rebuild more honest?

It depends on the state of the code. If the architecture holds and documentation and tests are usable, continuing is clearly cheaper. If only parts are rotten, you replace them incrementally (Strangler Fig). Rebuilding is only worth it once understanding and repairing would cost more than building new, and never just because a lot has already been invested.

Q: What if the old developer does not cooperate or is no longer reachable?

Then account ownership decides. If the store accounts are in your name, you keep control and a new developer can take over. If they sit with the vanished provider, only platform support helps on Google Play. The signing key is secondary: with modern Play App Signing, an upload key can be reset.

Q: What does it cost to take over an existing app?

Takeover, audit and onboarding calculate in person-days, at the German-speaking freelancer rate of around 104 euros per hour. There is no flat takeover price list on the market, because almost only prices for new development get published; the exact effort only comes from the assessment. The general cost logic is in a dedicated cost guide.

Yes, an existing app can be taken over and developed further by another developer, even when the original agency is gone. The prerequisites are access to the source code, the store accounts and the usage rights. It always starts with an assessment that honestly clarifies whether the app can be stabilised or whether a rebuild is cheaper.

By Tobias BoehmUpdated June 4, 2026

Can my app even be taken over?

Almost always, yes. Having an existing app taken over and developed further by another developer is a well-established process, even if the original agency is insolvent, has walked away or has simply become too expensive. The serious question is not whether it is possible, but whether the code can be saved or whether a rebuild ends up cheaper.

No one makes that decision from gut feeling. It starts with an assessment: a code audit, a check of the rights, and securing the access. Only then can you draw up a reliable plan with a fixed price. The table below shows when each route is the right one.

A takeover is almost always a question of risk and control, not primarily a question of features. The honest assessment first protects you from the most expensive option: building blindly on a foundation that does not hold.

Take it over or honestly rebuild?³ ⁴ ⁵

The state of the code decides this, not a percentage: there is no serious threshold along the lines of "rebuild once X percent of the code is incomprehensible". The table below relies instead on recognised patterns from software engineering and keeps the decision factual rather than emotional.

One rule up front, because it prevents the most common mistake: money already invested is no argument for continuing. Only the future cost of each route counts.

Take over, replace incrementally or rebuild: decision logic by state of the code
Situation	Recommendation	Why
Architecture sound, documentation and tests usable	Continue	The code is healthy enough. Takeover and further development are clearly cheaper than a rebuild.
Only parts are rotten, app is business-critical	Replace incrementally (Strangler Fig)	Old and new run in parallel until the old is replaced. Avoids the risk of a big-bang swap³.
Understanding and repairing costs more than rebuilding	Rebuild	Missing documentation and tests make the comprehension effort explode. Full rewrites, however, fail often, an estimated 70 percent⁴. Choose only if repair really would cost more.
"We have already invested so much"	Not a valid criterion	The sunk-cost trap: money already spent distorts the decision⁵. Only which route is cheaper from today onwards counts.

Rule of thumb: continue when the architecture holds; replace incrementally when only parts are rotten; rebuild only when understanding plus repairing would cost more than building new, and never because a lot has already been invested.

Is my code even salvageable?

An assessment decides that, not a gut feeling. What gets checked is the architecture and code quality, the state of the dependencies and libraries, the security situation and, above all, how much undocumented business logic sits in the code. If documentation and tests are missing, that logic has to be laboriously recovered from the code, and that is exactly the most expensive, most underestimated item.

The reason lies in the nature of someone else's software: the biggest effort is not writing new code, but understanding existing code. A peer-reviewed study measures that developers spend around 58 percent of their time understanding code and only a small share writing it¹. In undocumented foreign code, this understanding dominates the first weeks, long before a single new line is written.

For you as a decision-maker that means: demand an honest assessment before any fixed price. Anyone who quotes you a flat price for further development without looking at the code is guessing, not checking.

How to recognise a healthy project: a readable structure, maintained dependencies, existing tests, and a traceable build and deploy documentation. If all of that is missing, the code is not the problem, the effort of understanding it at all is.

Who owns the app: code, accounts, keys and data?

The most important lever in any takeover is not the code, but the ownership of the developer accounts. Whoever holds the Apple or Google account controls updates and the transfer of the app. On Google Play, only the account owner can start the transfer, and if that owner is unreachable, there is no self-serve transfer left⁷. On Apple, the app transfer is likewise initiated by the account holder⁶. If the account is in the name of the former provider rather than yours, they can lock you out of your own app in a dispute. Moving the account onto your own company account is therefore often the first practical rescue step.

Secondary, but important on Android, is the app signing key. For new apps, Play App Signing has applied since August 2021: Google holds the signing key, the developer holds only the upload key, and that can be reset via the Play Console. So there is no risk of total loss here. It is different with the old legacy signing for apps from before August 2021: if the developer holds the only signing key and does not hand it over, the app can no longer be updated and has to be republished as a completely new app, losing reviews and the installed base⁸. The decision-maker's question in any Android takeover is therefore: Play App Signing or legacy?

With code ownership, a trap applies in Germany that many overlook: software is protected by copyright, and without a contractually agreed, exclusive and transferable usage right including the right to modify and to receive the source code, you may legally not even be allowed to have the code changed, even if the files physically sit with you⁹. A statutory claim to the source code exists only with a corresponding agreement; the leading case law on this is the German Federal Court of Justice decision X ZR 129/01.

When switching, the data processing agreement (Art. 28 GDPR) must also be concluded anew and the old one ended, so that databases and backups are handed over cleanly and deleted at the former provider. Rule for new contracts: store accounts, code rights and data access belong to the client.

What do I need to secure from the old developer?

Everything a new developer needs to build, publish and run the app. Secure it while the contract with the old provider is still running and the handover is cooperative; whatever is missing later is hard to recover in a dispute.

Repositories with owner rights on the Git host, not just read access.
Store accounts with Apple Developer and Google Play, explicitly including the account ownership.
Signing keys and keystores together with their passwords.
Push and payment certificates.
CI/CD pipelines and their configuration.
Cloud and backend accounts.
Database access.
Domains and DNS management.
API keys and other secrets.
Build and deploy documentation, so a new developer can publish at all.

Order matters: access first, terminating the old contract only afterwards. Anyone who terminates before everything is secured throws away their only lever.

How does a takeover work?

An orderly takeover follows a fixed order that deliberately starts with risk mitigation and only goes deep afterwards. The first steps amount to an assessment; they are the basis for any reliable fixed price.

The phases of a takeover, in order

Secure access and assets, before terminating the old provider: repos, cloud, CI/CD, store accounts, domains, secrets and keys. This step prevents most showstoppers.
Inventory and assessment: capture code, documentation, access, contracts, dependencies and infrastructure in full.
Code audit: review the architecture, assess code quality and maintainability.
Assess dependencies and stack: outdated libraries, version conflicts, OSS licences and platform support.
Analyse technical debt: name, quantify and prioritise the debt.
Security review: check vulnerabilities, secrets in the code, outdated encryption and data flows.
Reconstruct missing documentation: trace environment variables, build and deploy paths, and the business logic.
Stabilise: fix urgent defects in production and restore the deployment pipeline.
Draw up a recovery plan: realistic milestones, timeline, budget and, where needed, a reduced scope.

Industry guide values, not to be read as fixed figures: initial assessment around 2 to 4 weeks, first visible progress often within 5 to 10 days, the full recovery strongly scope-dependent over several months.

What does taking over an existing app cost?

A takeover is calculated in person-days, not from a price list: audit, onboarding and further work are billed by effort, and the most reliable figure for that is the day rate. The average freelancer hourly rate in the German-speaking market in 2025 is around 104 euros², roughly 700 to 960 euros per day; senior specialists and agencies sit above that. There is no flat takeover price list on the market, because almost only prices for new development get published.

For an audit there is no reliable price list for the German-speaking market; concrete audit prices come only from international providers in US dollars. As a rough orientation, the day rate suggests an effort of about 3 to 10 person-days, so roughly 2,500 to 9,000 euros. That is an illustration, not a quote.

What the takeover costs in a specific case depends above all on the state of the code. How effort and price come together for app projects in general is covered in a dedicated cost guide.

These figures are market and model values for orientation, not fixed prices and not quotes. Which figures apply to a specific takeover only emerges from the assessment.

What if the old developer is no longer reachable?

This is the most dangerous case, because the handover then no longer runs cooperatively. Again, account ownership is decisive. If the store accounts are in your name, you keep control over updates, and a new developer can take over. If they sit with the vanished provider, it gets tough: on Google Play, without a reachable owner there is no self-serve transfer, leaving only the route via platform support⁷.

With Android signing, it again comes down to whether Play App Signing is active: then a lost upload key can be reset via the Play Console and updates remain possible⁸. Only with the old legacy signing without a handed-over key does it get critical. If you are missing the code or access entirely, a clean rebuild on the basis of the still available data is often the faster route than trying to wrestle everything from a non-cooperative provider.

Practical order in an emergency: secure accounts and data, move the ownership onto your company account, clarify the signing situation, and only then decide between repair and rebuild.

Three numbers worth knowing

58 %¹

of developer time goes into understanding existing code, only a small share into writing it. The biggest and most underestimated item of any takeover.

€104/h²

average freelancer hourly rate in the German-speaking market in 2025, roughly 700 to 960 euros per day. Audit and onboarding calculate in such person-days.

9 % / 6 %¹⁰

of apps on Google Play and the App Store had no update for over five years (as of 2022, single-vendor study). An orphaned app is no edge case.

My take

I am not a self-styled rescue expert with a list of saved apps. What I bring is something plainer and more reliable: for over ten years I have regularly stepped into someone else's inherited codebases, from onboarding onto large legacy systems to working on security-critical software. I can honestly judge whether your app is salvageable, and I will tell you just as honestly when it is not.

That is why a takeover with me does not start with a flat quote, but with an app check from 3,999 EUR: the structured first step that checks code, rights and access and honestly clarifies whether stabilising and continuing is worth it or whether a rebuild is the cheaper route. For complex legacy apps, the deep dive from 7,999 EUR goes further and leads to a binding fixed-price offer.

If the honest result is "rebuild", then I say so, even if it costs me the larger job. A full end-to-end development at a fixed price is available with me from 19,999 EUR. But we only go that far once the assessment shows that repairing really would cost more than building new.

Frequently asked questions about app takeovers

Can I have my existing app taken over and developed further by another developer?

Is it worth saving the app, or is a rebuild more honest?

What if the old developer does not cooperate or is no longer reachable?

Who owns the code, and do I get the source code?

In Germany, software is protected by copyright. Without a contractually agreed, exclusive and transferable usage right including the right to modify and to receive the source code, you may not even be allowed to have the code changed, even if the files sit with you. A claim to the source code exists only with a corresponding agreement; the leading case is the German Federal Court of Justice decision X ZR 129/01.

What does it cost to take over an existing app?

Sources

This page draws on the following sources. Primary sources are vendor documentation, laws, case law and peer-reviewed studies; industry guide values are market-corroborated experience values.

Have it checked whether your app can be saved

In a free intro call I assess your situation and tell you honestly whether a takeover is worth it or whether a rebuild is the better route. Tobias Boehm, senior app developer from Northern Germany.