Your Developer Disappeared. How to Take Over Your Own App

It rarely ends with an announcement. Replies get slower, then arrive at odd hours, then stop. There is a half-finished feature in the app, an invoice you are not sure you should pay, and a growing suspicion that nobody alive knows how the thing works.

This happens to good businesses with sensible contracts. What follows is the order we work in when someone hands us a project in that state, and the reasoning behind the order, because the sequence matters more than the speed.

Start with the accounts, not the code

Code can be read by anyone competent. An account you cannot get into is a different kind of problem, because recovery depends on a company's support process and on proving you are who you say you are, and that can take weeks you will want back later.

So before anyone opens an editor, find out whose name is on each of these, and move anything that is not yours.

• The domain registrar, and the DNS records, which may live somewhere else entirely
• The code repository, including whether it sits under a personal account rather than a company one
• The hosting and database accounts, and the card paying for them
• The Apple and Google developer accounts, which are the hardest of all to recover and the easiest to lose
• Email, analytics, payment processing, and any third-party service the app calls

Two of these cause most of the lasting damage. An app store listing published under a developer's own account cannot simply be handed over; the app is transferred between accounts or republished from scratch, and republishing means losing the reviews and the install base attached to it. A domain registered on a personal card expires quietly on a date nobody has in a calendar.

Work out what you actually own

The next question is whether the code you have is the code that is running. This sounds paranoid and is routinely false. A repository handed over at the end of a contract is frequently behind the live site, because the last few fixes were made somewhere else, or the deployment was done by hand from a laptop that is no longer in the building.

The repository history answers more than the code does. A long series of small commits by one person tells you the project was maintained. A single enormous commit called something like initial tells you the history was discarded, and with it any explanation of why anything is the way it is. Gaps of months in the middle tell you where the attention went.

Look for a README, environment examples, and any file describing how to run the thing locally. Their absence is not fatal. Their presence tells you someone expected a successor, which usually correlates with everything else being in better shape.

Read it before anyone changes it

There is enormous pressure at this point to show progress, and the fastest way to look busy is to start fixing. It is also the fastest way to destroy the only advantage you have, which is that the current behaviour is known and the current bugs are at least familiar.

A reading pass comes first: what the app does, what it talks to, where the data lives, and what would happen if it stopped. That pass produces a written description of the system, which in a lot of inherited projects is the first one that has ever existed. Everything after it is cheaper because of it.

The five checks that decide everything else

Some findings change the plan rather than adding to a list. These are the ones worth doing in the first week, in this order.

1. Can one customer reach another customer's data? Make two accounts and try it, rather than reading the code and assuming. This is the finding that stops a release.
2. Are any secrets public? Keys committed to the repository, or built into the files a browser downloads, are already exposed and need replacing rather than hiding.
3. Can the app be rebuilt from the repository alone? If it only builds on a machine nobody has, you do not yet have a working handover, whatever the contract says.
4. Is anything backed up, and has a restore ever been tried? An untested backup is a belief, not a backup.
5. If money changes hands, is a payment confirmed by the payment provider or by the browser? The browser is not allowed to be the authority on this, and in inherited code it often is.

The first two are the ones that most often turn an orderly handover into an urgent one. We go through the same list on AI-built apps, for the same reason: the origin differs, the failure modes converge.

The rebuild instinct, and when it is right

Almost every developer looking at inherited code will want to rewrite it, and will say so with conviction. Some of that is genuine judgement. A good deal of it is that reading someone else's work is slow and unglamorous, while starting again is neither.

Be suspicious of a rebuild recommended in the first week. A rewrite throws away every undocumented decision the old code encodes, including the ones that look wrong and exist because a real customer complained. It also restarts a clock you have already paid for once.

There are honest reasons to rebuild: a framework that no longer receives security updates, a data model that blocks the next year of the business, or a codebase so tangled that small changes keep causing distant breakages. What those have in common is that someone can state the reason in a sentence a non-technical owner understands. If nobody can, the answer is usually to finish what exists.

Getting moving again

The first change should be small, boring and visible: a copy fix, a broken link, a version number. Not because it matters, but because it proves the whole chain works, from a developer's machine through the build to the live site. Until something has travelled that path, nobody knows whether they can ship at all, and that is the question the business actually needs answered.

After that, put a test around the one flow that must never break, usually signing in or paying. Then you can move quickly again, because a mistake fails a check instead of a customer.