Your Developer Abandoned the Project: A Recovery Plan for Unfinished Software
Your developer or agency disappeared mid-project. What to secure in the first 72 hours, how to assess an unfinished app, and how to choose a team to finish it.
Key Takeaways
- In the first 72 hours, secure access before anything else: domain, hosting, code repositories, app store accounts, and every third-party service the app depends on.
- Send a written, dated request for the code, credentials and documentation. It costs nothing and matters later if there's a dispute.
- "80% done" is almost never true. Get an independent assessment of what exists, what works and what's missing, before anyone quotes for finishing it.
- There are three options: finish what's there, stabilise and continue in stages, or rebuild the parts that can't be saved. The assessment, not frustration, should decide.
- Choose the next team on how they handle inherited code: a paid assessment first, honest findings, and incremental delivery in your accounts.
A developer stops answering. An agency goes quiet, or closes. The project is half built, the money is mostly spent and the launch date is close. It is one of the most stressful situations a business owner can face with software, and the first few days decide how much can be saved. This guide is the plan we follow when a client arrives in that position. If the previous supplier is still reachable and cooperating, our handover checklist is the better starting point.
The first 72 hours: secure access
Code can be recovered or rewritten. Lost accounts are harder. Make a list and work through it today.
| What | Why it matters | What to check |
|---|---|---|
| Domain name | Whoever controls it controls your website and email | Who is the registrant at the registrar? Can you log in? Is the renewal date close? |
| Hosting and cloud (AWS, Azure, Google Cloud, OVHcloud, Vercel...) | The running application and its database live here | Whose account and payment card? Do you have admin access? |
| Code repositories (GitHub, GitLab, Bitbucket) | The source code and its history | Is the repository in your organisation or the developer's personal account? |
| App store accounts (Apple, Google Play) | Mobile apps are tied to the developer account that publishes them | Was the app published under your company's account? |
| Third-party services (payments, email delivery, maps, analytics, authentication) | The app stops working if a key is revoked or a bill goes unpaid | Which services, whose accounts, and where are the keys stored? |
| Database backups | Your data, if the hosting disappears | When was the last backup, and can you download it? |
Three practical rules:
- Pay the bills yourself. If hosting or the domain is on the developer's card, an unpaid invoice can take your service offline. Ask the provider about moving the account or the service to your company.
- Change what you can. For every account you control, rotate passwords and API keys and remove access for people who have left.
- Don't delete or "clean up" anything yet. The next team will need the full history to understand what was built.
If the mobile app was published under the developer's own account, both stores support moving an app to another account without losing its users and ratings: see Apple's app transfer overview and Google's transfer apps to a different developer account. Both need the current account holder to start the transfer, which is another reason to keep the relationship as civil as you can.
Put your request in writing
Even if the developer has gone silent, send a short, dated written request by email and, in France, by registered letter (lettre recommandée avec accusé de réception). Ask for:
- the complete source code and repository access;
- all credentials and API keys for the services the app uses;
- documentation, designs and anything else delivered or paid for;
- confirmation of the status of any unpaid invoices.
Keep it factual and polite. If the relationship ends in a dispute, a record of what you asked for and when will matter. It also matters for ownership: who owns the code depends on what your contract says, and our guide on software IP ownership explains why paying for the code does not, on its own, make it yours under French law. For significant amounts, get a lawyer involved early.
Assess what you actually have
Once you have the code, resist the urge to hire whoever promises to "just finish it". Unfinished projects are rarely as complete as the last status report said. The usual gaps:
- Screens without the logic behind them. The interface looks finished, but forms don't save, emails don't send and payments aren't connected.
- Features that work only in the demo. Hard-coded data, test accounts and skipped validation.
- No deployment process. The app runs on the developer's laptop or a server configured by hand, and nobody knows how to release a new version.
- Missing pieces nobody listed. Admin tools, password reset, error handling, backups, security.
An independent assessment, typically one to two weeks, should tell you:
- Can it be built and deployed from the repository alone?
- What works, tested end to end, and what only appears to work.
- Code quality and security, at a level that tells you whether the foundations are sound.
- What's missing against what you need for launch, with an estimate for each part.
- A recommendation: finish, stabilise and continue, or rebuild specific parts.
This is the core of a technical audit, focused on one question: what will it take to get this live?
Finish, stabilise or rebuild?
| Option | When it fits | The risk |
|---|---|---|
| Finish as is | The foundations are sound, the code is readable and the gaps are features, not structure | Low, if the assessment confirms it |
| Stabilise, then continue | The core works but there are weak spots: no tests, fragile deployment, security gaps | Moderate; needs a team comfortable with inherited code |
| Rebuild parts | Specific areas are unsalvageable, but data models, designs or some modules can be kept | Moderate; scope creep if not tightly defined |
| Rebuild everything | The code can't be built, the technology is unsuitable, or almost nothing works | High: it takes longer than anyone expects |
Full rewrites are tempting after a bad experience, and usually riskier than they look. Our guide on rescue or rewrite goes through the decision in detail.
Choosing a team to take over an unfinished app
Plenty of agencies will happily start something new. Fewer are good at taking over someone else's half-built code. When you compare them, look for:
- A paid assessment before a fixed quote. Anyone who quotes to "finish" an app without reading the code is guessing.
- Honest findings, including the parts that are better than expected. A team that condemns everything it didn't write is selling a rewrite.
- Experience with inherited code, with examples you can check.
- Incremental delivery: small, working releases from the first weeks, not a big reveal months later.
- Everything in your accounts, so this never happens again. See how to vet a software development agency and our guide on spotting junior teams and hidden subcontractors.
How to make sure it never happens again
- Repositories, hosting, domains and app store accounts in your company's name from day one, with the developer invited, not the other way round.
- Regular, working deliveries you can see and test, not status reports.
- Documentation and deployment instructions delivered with each milestone.
- A contract with an explicit IP assignment, a handover clause and named people.
- For software you license rather than own, consider source code escrow.
Frequently asked questions
Can I get my code back if the developer won't respond? If the code is in a repository you control, you already have it. If it's in the developer's own account, send a written request, and if that fails, take legal advice: your rights depend on your contract and on what you've paid for.
How much of the original budget is usually lost? It varies widely. The assessment is what tells you: sometimes most of the work is usable, sometimes very little. Don't trust an estimate made before anyone has read the code.
Should the new team use the same technology? Usually yes, if it's a mainstream, well-supported stack and the code is reasonable. Changing technology turns a rescue into a rewrite.
My app is on the App Store under the developer's account. Is it lost? Not necessarily. Apple and Google both support transferring an app to another developer account while keeping its users and ratings, but the current account holder has to start it. If they won't, you may have to republish under your own account and migrate users.
FNB Solutions takes over unfinished and struggling applications: a short paid assessment first, then a plan to stabilise and deliver, with everything in your accounts. See our software rescue service, or tell us what happened.
Sources
- Apple, overview of app transfer (App Store Connect Help)
- Google, transfer apps to a different developer account (Play Console Help)
- Code de la propriété intellectuelle on Légifrance, article L131-3 (form of assignments of author's rights)