Your Developer Disappeared Mid-Project: How to Take Over a Half-Built App

Short answer: if your developer or agency has gone quiet with the app half built, don't start by hiring someone to "finish it". Start by securing access to everything you've paid for — the code, the servers, the domain, the app store accounts — then get an independent audit of what actually exists. Only then decide whether to rescue the current code or rebuild the parts that can't be saved. This guide walks through each step. It happens more often than founders admit: a freelancer takes a full-time job, a small agency loses its only developer, or the relationship breaks down over scope and payments. The good news is that a stalled project is rarely a total loss, as long as you act in the right order.

The first 72 hours: secure access before anything else

Before you discuss blame, refunds, or a new team, make a list of every account the project depends on and confirm who controls each one. Ask the previous developer politely and in writing to transfer anything still in their name.

• Code repository (GitHub, GitLab, Bitbucket) — you need owner access, not just a zip file. The commit history shows what was built and when.
• Cloud hosting and database (AWS, Google Cloud, a VPS) — including billing, so the servers don't get switched off when a card expires.
• Domain and DNS — the registrar account, not just the domain name.
• App Store and Google Play developer accounts — these should be registered to your company. Transferring an app out of someone else's account is possible but slow.
• Third-party services — payment gateway, SMS and email providers, maps, push notifications, analytics. Each has API keys tied to an account.
• Design files and documents — Figma, the scope document, any API documentation.

If any of these are in the developer's personal name, that's your highest priority. It's also the most common form of accidental lock-in — our guide to avoiding vendor lock-in explains how to prevent it next time.

Get an independent code audit

Once you have the code, ask a new team to audit it before you commit to a plan. A useful audit is short and answers plain questions, not just "the code quality is poor":

1. Does it build and run? Can the new team set it up from the repository alone?
2. What percentage of the agreed scope actually works end to end, screen by screen?
3. Is the backend structured sensibly — authentication, roles, data model — or would every new feature fight it?
4. Are there security problems: passwords or API keys in the code, missing access checks, unencrypted sensitive data?
5. Are the main libraries and frameworks current and supported?
6. Is there any documentation, test coverage, or deployment process?

An audit typically takes a few days, not weeks, and it turns a stressful unknown into a list of facts you can make decisions with.

Rescue or rebuild?

This is the decision founders most want to get right. In our experience, it's rarely all-or-nothing — most projects end up partly rescued and partly rebuilt.

Rescue vs rebuild

Rescue the existing code when	Rebuild when
It builds, runs, and most screens work	It doesn't build, or no one can set it up
The data model fits your business	The data model fights every core workflow
Problems are bugs and missing features	Problems are structural: security, auth, architecture
The tech stack is current and common	It uses an outdated or obscure stack few teams support
You have real users or data on it already	Nothing is live yet and the remaining scope is large

A common middle path: keep the backend and data if they're sound, and rebuild the front end or mobile app on top of them. Or keep the app screens and replace a fragile backend with a properly designed backend and API. If the MVP has grown into several half-connected tools, read signs your quick MVP has become unmaintainable.

Handing over to a new team

Treat the new engagement as a fresh project with a clear scope, not a vague "please finish it". Give the new team:

• The audit findings and the decision you made from them
• An updated scope: what's done, what's being kept, what's left, and what's out
• Access to every account from the checklist above
• Any contact you still have with the previous developer, for questions about undocumented parts

Our guide to briefing a software agency when you're not technical has an outline you can reuse, and 12 questions to ask before hiring an agency will help you avoid a repeat.

How to stop it happening again

• Register every account in your company's name from day one, and give developers access rather than ownership.
• Ask for weekly demos of working software, not status messages.
• Make sure code is pushed to your repository every week, not delivered at the end.
• Put code ownership and handover terms in the contract.
• Agree a maintenance plan before launch so there's a named team responsible afterwards.

FAQ

---

Stuck with a half-built app? We take over existing mobile apps and custom software projects, starting with an honest audit. Book a free call and we'll tell you what can be saved.