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

First, the reassurance founders do not hear enough: an abandoned build is not a dead product. Existing design decisions, user feedback and working code can still be useful. What matters now is finding out which of those assets you can access and which parts perform the task the customer needs. Preserve that evidence before authorizing another build.

Step 1: confirm account control and preserve the working version

Confirm the rights and access your business has, and what your agreement requires for a handover. Record the business-controlled owner and recovery route for each of these:

• 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 provide secrets, without copying secret values into the inventory

If the previous developer still answers, ask politely and in writing. Frame it as routine: explain that the business needs verified operating and recovery access. If they do not answer, review each provider’s recovery process and your business records. Payment records alone do not guarantee recovery.

Step 2: find out what you actually have

A status report and a demonstration are not a complete inventory of the product. Check whether another authorized engineer can reproduce the build and demonstrate the required journeys. Before committing 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?

This is exactly what 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

Three useful options are to complete the verified gap, replace a defined weak boundary, or stop. The assessment should explain the evidence and assumptions behind its recommendation.

Finish it. The foundation is sound and the gap is missing features, bugs and launch work. Compare that bounded completion scope with the alternatives.

Rebuild the weak parts. Some of the foundation cannot carry the product, often authentication, the data model or payments. Those parts are rebuilt while the rest is kept. Where feasible, review the replacement alongside the live version and plan migration, cutover and recovery around the product’s operating constraints.

Stop. Occasionally the right answer is that the market has moved or the remaining cost is larger than the opportunity. Establish the next business question before authorizing 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

Put continuity requirements in the next engagement rather than assuming what caused the previous problem. 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?
• What review cadence and working evidence will we agree?
• If you disappeared tomorrow, could another developer pick this up from what you leave?

Ask for the answers and responsibilities 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 verified gap, not the percentage the old team reported. Separate work that already functions, repairs needed to make the foundation reliable, remaining features, and release work. A nearly complete interface can still depend on missing permissions, payment state, data migration or production configuration.

Ask the new team for a completion map with an acceptance case beside each item. For a paid account, the case should show a test purchase producing the right access and a failed or repeated notification reaching the correct state. Identify unknowns that require investigation before they can receive a reliable price.

• 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 cost from today forward. A replacement plan also needs to price migration, continuity and reproducing 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?

Record exactly what you received. A hosted demo may depend on accounts you cannot access; a ZIP may omit version history, migrations or service configuration. Ask a reviewer to reproduce the application in a controlled environment and identify missing dependencies. Preserve the current live system while checking whether the handover is complete.

Keep secret values out of ordinary documents. A setup guide can list environment variable names and the account that provides each value, while access is shared through provider permissions or an appropriate secret-management process. Our handover guide provides an ownership register and a practical check of whether the next team can operate the product.

Step 5: get to real users, then keep going

The goal is a working product that delivers the intended customer or business result. Launch with the smallest version that delivers the core promise, measure what people actually do, and build the next thing from that evidence instead of from the original wish list.

If your developer has gone quiet and you are not sure what you are holding, book a call. We can help define the next assessment and the evidence needed to decide whether to finish, replace part of the system or stop.