My developer abandoned my app. What do I do now?

First 48 hours: secure what you own

The most urgent risk is not the unfinished features. It is losing access to the things the product already depends on. Many founders discover that the repository, the hosting account or the domain was registered under the developer's personal email. While the relationship is friendly, fixing that is a five-minute task. Once it is not, it can take weeks.

Make a list of every service the app touches and check who the owner is. Where you are not the owner, ask for a transfer in writing, politely and with a date. Keep the tone neutral: you want the handover, not an argument. If the developer is unreachable, most providers have an account recovery process for the paying customer or the legal owner of the business, so collect your invoices and contracts now.

• Code repository (GitHub, GitLab, Bitbucket): you should be the organisation owner, not a collaborator
• Hosting and cloud accounts (Vercel, Netlify, AWS, Google Cloud, Supabase, Firebase and similar)
• Domain registrar and DNS
• Database and its backups
• Apple App Store Connect and Google Play Console, if there is a mobile app
• Payment provider (Stripe or similar), email sending service and any API keys for AI or third-party services
• Design files and any documentation or specification

Revoke and rotate, then recover the code

Once you control the accounts, remove the former developer's access and rotate the secrets they could see: API keys, database passwords, payment keys and app store keys. This is not an accusation. It is standard practice whenever someone leaves a project, and any professional developer will expect it.

Then make sure you have the full source code, not only what is deployed. Ask for the complete repository history, environment variable names (without values if they insist, since you will rotate them anyway), database schema and migrations, and any build or deployment scripts. A product that runs in production but cannot be built from the code you hold is a serious finding, and it is better to know it now.

Get an honest assessment before you commit to a plan

The next team's first job is to tell you the truth about what you have. A useful assessment answers a short list of questions in plain language: does the code build and run, how much of what was promised actually works, what is risky (security, data, payments), and what can be kept. It should end with options and a recommended next step, not a sales pitch.

Be careful with anyone who quotes a full rebuild before reading the code, and equally careful with anyone who promises to finish everything quickly without looking. Both are guesses. On the project takeover page you can see how Servify Labs runs this step.

1. Read access

   Give the assessing team read access to the repository, hosting and database through invitations, not shared passwords.

2. Run it

   They build and run the app in a separate environment, so production is not touched.

3. Compare

   They compare what exists with your specification, contract or feature list and mark each item as working, partial or missing.

4. Report

   You get a written summary of the state of the code, the main risks, what can be kept and two or three options with rough effort.

Finish the existing code or rebuild?

Most abandoned projects are neither perfect nor worthless. In many cases the data model, the integrations and large parts of the interface can be kept, while specific areas such as authentication, payments or a fragile part of the backend need to be redone. A full rewrite is justified when the code cannot be built, when the security problems are structural, or when the chosen technology cannot support what the business needs next.

The decision should come from the assessment and your plans for the product, not from the new team's preferences. Ask the team to explain each recommendation in terms of risk and cost to you.

• Usually worth keeping: a sound database structure, working integrations, finished screens, tests that pass
• Usually worth redoing: hard-coded secrets, missing access control on data, payment flows nobody can explain, code that only one person could deploy
• A rewrite signal: the project cannot be built or deployed from the repository you hold

Choosing the next team

After one bad experience, it makes sense to choose the next team for continuity and transparency rather than for the lowest quote. Look for a team that puts ownership in writing, works in your accounts, shows progress in short cycles and makes it easy to stop.

Servify Labs is an AI-native product studio: senior engineers who use AI tools, including Claude, to work fast without lowering quality. The client owns the code, the designs and the infrastructure from day one. After the first call we send a quote and a written proposal within about 20 minutes, hold a second call the next day, and start the day after the agreement is signed and the first sprint is paid. Ongoing work runs in two-week sprints from $3,500, paid upfront per sprint, and you can pause or cancel anytime.

• Ask who owns the code and accounts, and get the answer in the contract
• Ask how often you will see working software
• Ask what happens if you want to stop or switch teams
• Ask for the first step to be an assessment, not a build

When Servify Labs is not the right fit

We are not a good fit if the budget is below our offer, if you only need a quick patch to get through a demo, or if there is no plan to keep building the product after it is fixed. In those cases a single freelancer for a narrow, well-defined task is often the better choice, and we will say so on the call.

Frequently asked questions

Related

• Your developer is gone. Your product doesn't have to be.