Your Developer Disappeared: A Calm Step-by-Step Plan to Rescue Your App

You paid a developer. The launch date passed. Now messages go unanswered, or the app you received crashes, or the developer says it will "be done soon" for the fourth month.

If this is you, take a breath first. This situation is common, and it is often more fixable than it feels. What matters is the order in which you act. Panic makes people skip step one, and step one protects everything else.

This guide is written for non-technical founders. You do not need to read code to follow it.

Step 1: Protect what is yours, today

Before you argue with anyone, find out who controls your project's accounts. These are the doors into your product:

• The code. Is it in a code repository (such as GitHub) that you own, or in the developer's personal account?
• The domain name. Is it registered in your name and email?
• The hosting or server. Who holds the login?
• App store accounts. Apple and Google developer accounts should be yours.
• Third-party services. Payment keys, SMS, email, maps, analytics, databases. Whose account are they under?
• Backups. Does a recent copy of the data exist, and where?

For each one, write down: who owns it, who has the password, and when it was last used.

If something is in the developer's name, you can still often recover it, but start by asking politely and in writing. Many developers who went quiet are not villains. They are overloaded or stuck. A calm, clear message often works. If it does not, keep copies of your messages and agreements, because you may need them.

Do not delete anything, reset anything or pay anyone else to "start over" yet. You may destroy the only copy of work that exists.

Step 2: Gather what exists

Collect everything, even if it looks like a mess:

• The original agreement, quotes and invoices.
• Every message about what was promised.
• Designs, mock-ups and written requirements.
• The code, if you can get it. Ask for a full copy, not a screenshot.
• Logins to the test version of the app, so someone can try it.

You are building a file. It will let a new person understand the project in hours instead of weeks.

Step 3: Learn what state it is really in

Before you decide anything, you need a true picture. This is called a code audit: a skilled person reads the code and tests the app, then tells you in plain language:

• What works, what is half-built and what is broken.
• Whether the code is organised enough to build on, or tangled.
• Whether there are security problems, such as passwords stored badly, keys left in the open, or no protection on payment steps.
• How much work remains, and in what order.

A good audit report is written so you can understand it. It should end with options and rough costs, not just a list of complaints. If an agency tells you only that everything is terrible and you must pay them to start from zero, get a second opinion.

Step 4: Choose one of three paths

After an audit, you usually land on one of these.

Fix and finish. The code is decent. It needs bug fixes and the missing pieces. This is the cheapest path and the most common one when the original work was reasonable.

Partly rebuild. Some parts are good (maybe the screens), some are not (maybe the payment logic or the server). You keep what works and replace what does not.

Rebuild. The foundation is too weak to build on. Rebuilding is then cheaper than fighting the old code. You still keep what is valuable: the designs, the requirements and everything you learned from users.

Ask the person who audited the code to explain why they recommend one path, and what would change their mind.

Step 5: Set up the next relationship safely

Whoever you pick next, avoid repeating what went wrong:

• Pay in stages tied to work you can see, not all at the start.
• Keep the accounts in your name. The code lives in your repository and your developer is added as a member.
• Ask for short, regular demos, every week or two, on a version you can open yourself.
• Write down what "done" means for each stage, before the work starts.
• Ask for notes. A short document explaining how to run and update the app.
• Plan for the day this developer is gone too. It should be easy for a new person to take over.

Warning signs to watch for early

You can often see this coming:

• Long silences, then vague updates.
• No demos you can click yourself.
• Code or accounts only the developer can reach.
• "It works on my computer" for weeks.
• Asking for more money before showing progress.
• Reluctance to let anyone else look at the work.

None of these proves someone is dishonest, but they are reasons to ask for a demo and a code copy now, not later.

What if the app is live and breaking?

Then slow down and act in this order: make sure you have a backup, find out whether money or customer data is at risk, and stop the damage first (for example, turn off a failing payment step) before you fix anything else. Fix the urgent problem, then do the audit calmly.

How we can help

XpiriaTech offers a Code Audit and Rescue service for exactly this: we read what exists, tell you plainly where it stands, and then, if you want, we can fix and finish it or rebuild the parts that need it. We do not push a rebuild when the code is good enough to keep. See the Code Audit and Rescue service, or send us a message with what you have.