Your developer quit. Here is how to finish the app.

An abandoned build can still become a product. The design decisions, the user feedback and the code that works can all still be useful. Your first job is to find out which of those you can get to, and which parts do the task your customer needs. Save that evidence before you authorize another build.

Step 1: confirm account control and preserve the working version

Check what rights and access your business has, and what your agreement says about a handover. For each of these, write down the business-controlled owner and the recovery route:

• The code repository (GitHub, GitLab or Bitbucket), with every branch, not just main
• Hosting and cloud accounts (Vercel, AWS, Google Cloud, Supabase, Firebase)
• The domain registrar and DNS
• Apple App Store Connect and Google Play Console, if you have a mobile app
• Payment, email and analytics providers (Stripe, Resend, Google Analytics)
• The required configuration names and the accounts that supply the secrets (leave the secret values themselves out of the inventory)

If the previous developer still answers, ask politely and in writing. Treat it as routine: say the business needs to confirm it can operate and recover its own accounts. If they do not answer, go through each provider’s recovery process and your business records. Payment records alone do not guarantee you will get an account back.

Step 2: find out what you actually have

A status report and a demo do not tell you everything that is in the product. Check whether another authorized engineer can reproduce the build and show the required journeys working. Before you commit to a plan, answer three questions:

1. Does it run? Can a new developer clone the repository and start the app from the instructions alone, or does it only work on one person's laptop?
2. What is really finished? Which features work end to end with representative synthetic data, and which ones only look finished in a demo?
3. Is the foundation sound? Are the database, authentication and payments built in a way that can carry real users, or will they have to be redone?

Those are the questions our Diagnostic answers: a fixed price review of the code, the product and the money that ends in a written verdict you keep, whatever you decide next. If you would rather check yourself first, our 2 minute salvageability quiz can help prepare your questions. It does not inspect the code or replace a technical assessment.

Step 3: choose finish, rebuild or stop

You have three options: finish the work the assessment confirmed is missing, replace the specific part that is weak, or stop. The assessment should give the evidence and assumptions behind its recommendation.

Finish it. The foundation is sound, and what is left is missing features, bugs and launch work. Compare that defined list of work with the alternatives.

Rebuild the weak parts. Some of the foundation cannot carry the product, often authentication, the data model or payments. You rebuild those parts and keep the rest. Where you can, review the replacement next to the live version, and plan the migration, cutover and recovery around how the product has to keep operating.

Stop. Sometimes the right answer is that the market has moved, or that the remaining cost is larger than the opportunity. Decide what the business needs to learn next before you authorize another phase of work.

If you are weighing a rebuild, we explain the comparison in how much it costs to rebuild an app in 2026.

Step 4: pick a team that will not repeat the problem

You may never know for certain what caused the last problem, so write continuity requirements into the next engagement. Ask the new team these questions before work starts:

• Will all the work happen in my repository and my accounts from day one?
• How are the initial scope, unknowns, changes and ongoing costs approved?
• How often will we review the work, and what working evidence will I see?
• If you disappeared tomorrow, could another developer pick this up from what you leave?

Ask for the answers, and who is responsible for what, in writing. If you want more on spotting trouble early, read the 12 signs your dev team is failing you.

How much does it cost to finish an app someone else started?

Price the work an assessment confirms is left. The percentage the old team reported is no basis for a quote. Separate the work that already functions, the repairs the foundation needs to be reliable, the remaining features and the release work. An interface that looks nearly complete can still be missing permissions, payment state, data migration or production configuration.

Ask the new team for a list of what is left, with an acceptance case beside each item. For a paid account, the case should show a test purchase granting the right access, and a failed or repeated notification ending in the correct state. Mark the items that need investigating before anyone can put a reliable price on them.

• Keep: working journeys and components the review verifies.
• Repair: access, data or integration problems that block safe completion.
• Complete: remaining customer and staff tasks in the agreed launch scope.
• Release: deployment, testing, documentation and a usable handover.

Compare the costs from today forward. A replacement plan also has to price the migration, keeping the product running, and rebuilding behavior users already rely on. Use the build and operating-cost guide to understand recurring charges and costs that still need investigation.

What if you only have a demo or a ZIP file?

Write down exactly what you received. A hosted demo may depend on accounts you cannot get into. A ZIP may be missing version history, migrations or service configuration. Ask a reviewer to get the application running in a controlled environment and list the missing dependencies. Leave the current live system alone while you check whether the handover is complete.

Keep secret values out of ordinary documents. A setup guide can list the environment variable names and the account that supplies each value. Share the access itself through provider permissions or a proper secret-management process. Our handover guide has an ownership register and a practical way to check whether the next team can run the product.

Step 5: get to real users, then keep going

The goal is a working product that gives the customer or the business the result you intended. Launch the smallest version that delivers the core promise and measure what people do with it. Let that decide what you build next, even where it disagrees with the original wish list.

If your developer has gone quiet and you are not sure what you are holding, book a free consultation. We can help you work out what to assess next and what evidence you need to decide whether to finish, replace part of the system or stop.