What It Costs to Take Over an Abandoned App Codebase

The call usually starts the same way. The developer who built the app stopped answering email three weeks ago, or the agency said it was pivoting to other work, or the technical co-founder left and the repo is on a personal GitHub account. The app is live, customers are paying, and something small just broke.

This is more common than founders admit. Freelancers take full-time jobs. Small agencies close. Contract budgets run out in the middle of a build. In every case you are left with a pile of code, a production server you may not be able to log into, and a question: what will it cost to get someone else to take this over?

The honest answer is a wide range. In my experience a clean takeover of a small app runs about $8,000 to $25,000. A messy one with no tests, no documentation and tangled dependencies runs $40,000 to $150,000 or more, and sometimes the right move is to stop paying for the old code at all. The spread comes down to a few factors, and most of them are visible before you spend a dollar on development.

This post walks through what drives the cost, what to lock down in the first week, how a proper audit works, and how to decide between fixing and rebuilding. If the code was generated mostly by AI tools, read our breakdown of rescuing a vibe-coded MVP alongside this one, because the failure patterns differ.

Most takeover projects go wrong in the first five days, and not because of the code. They go wrong because nobody can prove who owns what. Before you hire anyone, collect the following and put it in one document.

• The source repository. Is it in an organization account you control, or on someone's personal GitHub? If it is personal, ask for a transfer to your organization today. A fork is a poor substitute because it drops issues, pull requests and deploy hooks.
• Cloud accounts. AWS, Google Cloud, Vercel, Render, Fly, Heroku, whatever hosts the app. You need an owner-level login that is tied to your email, not the developer's. If the billing card belongs to the developer, replace it.
• Domain and DNS. Check who the registrar lists as the owner. This one bites hard, because a domain held by an ex-contractor can take weeks to recover.
• App store accounts. Apple Developer and Google Play Console. If the app was published under the agency's developer account, you cannot move it without an app transfer, and Apple has its own app transfer process. Start this early.
• Third-party services. Stripe, Twilio, SendGrid, Firebase, Auth0, analytics, error tracking. List every one, who holds the admin login, and what it costs per month.
• Secrets. API keys, database passwords and signing certificates. Assume any key the old developer touched should be rotated once you have control.

Also read your contract. Look for the intellectual property clause. Many freelance agreements assign ownership only on final payment, and some agencies reserve rights to reusable components. If you find ambiguity, a one-hour call with a startup lawyer costs $300 to $600 and saves you from discovering this after you have spent $40,000 on the code.

My rule: do not start paying for engineering work until you can deploy the app to a staging environment you own. If you cannot do that, you do not control the product yet.

Two apps with the same feature list can differ by a factor of five in takeover cost. These are the variables that do it.

Tests. An app with a working test suite lets a new team change code and know what broke. An app with none forces them to test everything by hand, or to write tests before they touch anything. Writing characterization tests for an untested app often takes 15 to 30 percent of the total project budget.

Documentation and setup. If a new engineer can run the app locally in an hour from a README, great. If it takes a week of guessing at environment variables, that week is billed to you. Ask the developer for whatever they have, even a rough doc, while they still answer messages.

Dependency age. A React Native app pinned to a version from three years ago may need a staged upgrade before it can even build against current iOS or Android SDKs. Upgrading across several major versions is a project of its own, typically $5,000 to $20,000 for a mid-size app. Apple and Google both enforce minimum SDK levels, so an unmaintained app eventually cannot ship updates at all.

Architecture fit. A conventional app in a mainstream stack is easy to hand to someone new. A custom framework the previous developer invented, or an unusual language chosen for personal taste, narrows the pool of engineers and raises rates.

Data model quality. Bad code can be rewritten. A bad database schema holding two years of customer records is much harder, because every fix requires a migration. A schema with no foreign keys, duplicated fields and mixed formats can cost more to repair than the application layer on top.

Size. A 20-screen app takes less time to audit than a 200-screen one. Lines of code are a rough proxy, but the number of integrations and user roles is better. Each third-party integration adds risk, since API versions drift.

Never take over a codebase on a quote based on a screen share. Pay for an audit first. A good one takes a senior engineer one to two weeks and costs roughly $3,000 to $12,000 for an app of typical size, with larger systems running to $20,000. It produces a written report you own, whether or not you hire that team afterward.

Here is what the audit should cover, in the order I run it.

1. Can it build and run? Clone it, install it, boot it locally, deploy it to a fresh staging environment. Record every point that needed a workaround.
2. Security scan. Run dependency vulnerability checks and a secrets scan across the git history. Old repos often contain live API keys in commits from two years ago. Check authentication, authorization on each endpoint and how passwords and tokens are stored.
3. Dependency and platform health. List every package that is more than two major versions behind, deprecated, or abandoned. Check iOS and Android target SDK levels against current store requirements.
4. Data layer. Review the schema, indexes, backup status and whether a restore has ever been tested. Many abandoned apps have backups that have never been restored once.
5. Test coverage and CI. What exists, what passes, what is skipped. Is there a deploy pipeline or does the developer push from a laptop?
6. Hot spots. Find the five files with the most churn and the most bugs. They tell you where the real risk sits.
7. Cost to run. Pull the last six months of cloud and vendor bills. Founders often find $800 a month of forgotten infrastructure.

The deliverable should sort findings into three buckets: fix now because it is a security or legal exposure, fix soon because it blocks shipping, and leave alone. That third bucket matters. A takeover team that wants to refactor everything is billing for taste. If you want a model for what a clean code review looks like, the checklist in our guide to preparing a codebase for technical due diligence maps closely, since investors and acquirers ask the same questions.

If you are not technical, you can still judge the report. Does it name specific files and versions? Does it give a time estimate per item? Vague phrases like "technical debt is high" with no examples mean the auditor did not dig. Our piece on how to evaluate developer work covers other signals to look for.

These ranges are market estimates for US and Western European senior engineering rates, around $120 to $200 an hour for a good agency and less for nearshore teams. They exclude new features. They cover getting the app stable, owned and maintainable.

• Small, tidy app, still builds. A single backend, one client app, modest traffic, some documentation. Audit plus handover, access cleanup, a dependency refresh and monitoring: $8,000 to $25,000, taking three to six weeks.
• Mid-size app, no tests, outdated dependencies. Web app plus mobile apps, a few integrations. Audit, characterization tests on the critical flows, staged upgrades, CI setup and bug triage: $30,000 to $75,000, over two to four months.
• Large or tangled system. Multiple services, a custom framework, a messy schema, compliance needs such as HIPAA or payments. Expect $75,000 to $150,000 or more, and a real chance the audit recommends partial replacement.
• App that does not build at all. Missing source, lost signing keys, or only a compiled binary. Recovery can mean reverse engineering. Often it is cheaper to treat the live app as a spec and rebuild.

On top of those one-time numbers, budget for ongoing care. A stable app typically needs 10 to 20 percent of its build cost per year in maintenance, which our guide to app maintenance costs breaks down. A newly inherited app needs the higher end for the first year while the new team learns it.

Hourly versus fixed price also matters here. Takeovers are uncertain by nature, so a fixed price for the audit and a time-and-materials arrangement with a cap for the remediation tends to work better than a fixed quote for the whole job. Anyone who gives you a firm price for the whole job before the audit is guessing, or padding for the risk.

Founders want a rule here. There is not a clean one, but there are signals that tip the answer.

Fix it when the core data model is sound, the stack is mainstream, the app has paying users who rely on current behavior, and the audit finds problems that are local. Replacing a working product throws away years of edge-case handling that nobody wrote down. Those edge cases are the real asset.

Rebuild when the cost to fix approaches 50 to 60 percent of the cost to rebuild, when the stack is end-of-life, when the schema is the problem, or when you plan to change the product so much that you would rewrite most screens anyway. A rewrite is also the right call when security issues run through the whole design, such as business logic trusted on the client.

The middle path is a strangler approach. Keep the old system running, build new features and replacement modules next to it, and retire pieces over six to twelve months. It costs more in coordination but spreads the spend and keeps revenue safe. For apps built in AI coding tools, our article on rebuilding a vibe-coded MVP for production shows how that sequencing works in practice.

Whatever you pick, set a decision gate. After the audit, you choose fix, rebuild or strangler with real numbers in front of you. Do not let the same team that wrote the audit pressure you into the answer that gives them the biggest contract. Ask them what they would do if it were their money, and ask a second firm to read the report.

I have watched the same errors repeat, and each one adds weeks.

Starting new features on day one. Founders under pressure ask for the next feature immediately. Adding to an unaudited codebase compounds the debt and makes the audit findings stale. Freeze features for the first two to four weeks unless something is on fire.

Cutting off the old developer. Even a developer who has gone cold may answer a paid, scoped request. A two-hour knowledge transfer call at $150 an hour often saves 20 hours of detective work. Pay them, be polite, and ask for a recorded walkthrough of deploys, environment variables and known quirks.

Skipping monitoring. Before you change anything, add error tracking and uptime monitoring so you can see what normal looks like. Without a baseline you cannot tell whether your new team made things better or worse.

Ignoring the production database. Take a verified backup, restore it to a separate environment and confirm the app runs against it. Do this before the first deploy by anyone new.

Hiring for the cheapest rate. A $40-an-hour engineer who spends 200 hours reverse engineering costs more than a $150-an-hour engineer who has done five takeovers and spends 60. Ask for references from past takeovers specifically, not general portfolio work.

No handover standard for next time. Whatever you end up with, write down the rules that stop this recurring. Repos in your organization account. Cloud accounts owned by the company. A README that boots the app. Quarterly access reviews. These cost almost nothing and they are the reason some founders never face this problem twice.

Here is a schedule that works for a mid-size app. Adjust the pace to your size.

Days 1 to 5: secure repositories, cloud accounts, domains, store accounts and vendor logins. Rotate secrets. Back up the database and test a restore. Add error tracking and uptime alerts.

Days 6 to 15: run the audit. Get the written report with findings sorted into fix now, fix soon and leave alone. Get a ballpark for each item.

Days 16 to 20: make the fix-or-rebuild call with real numbers. If you are unsure, get a second opinion on the report for $1,000 to $3,000. That is cheap next to a six-figure choice.

Days 21 to 30: fix the security and legal exposures, set up CI, and get a deploy that any engineer on the team can run. Only then reopen the feature backlog.

By day 30 you should own every account, know what the app costs to run, have a tested backup and have a written plan with a budget. That is a far better position than most founders hold before the code goes missing, and it makes the next hire or the next investor conversation easier.

If you are holding a codebase you do not trust and want a straight read on whether to fix it or replace it, Book a free strategy call.