It usually starts quietly. Replies slow down, then stop. A deadline passes without a word. By the time you are sure the developer is gone, weeks have been lost, and the question is no longer why it happened. The question is what you do this week. This is the order we would work in, written so you can start today without anyone's help.
First, secure access to everything you pay for
Before anything else, find out which accounts your product actually lives in, and whether you can log into them: the code, the hosting, the database, the domain, the app store listings, the payment provider, and every third-party service with an API key. Anything registered to the developer's personal email is at risk, because the one person who can renew or delete it is the one who stopped answering.
Change the passwords you can, and add a second administrator from your own company wherever the service allows it. If something is in the developer's name, write down what it is now, even if you cannot move it yet.
Then send one calm message, in writing
Send a single, polite written request for a handover: the repository, the credentials, and any documentation or notes. Give a clear date and keep it factual. You may need that message later, and it is also the fastest route to a cooperative handover if the silence has an ordinary explanation.
Find out what actually exists
The demo you were shown is a different thing from the product. Ask an independent engineer to install the system from scratch using only what is in the repository, and to try the main workflows. If it runs, more value survives than it feels like. If it only ever ran on the developer's machine, the code may still be fine, but the knowledge around it is gone, and recovering that is usually the bigger job.
Then compare what exists with what was promised. Put the proposal or specification next to the product and mark every feature as working, half-working or missing. That list is the most useful document you will own this month.
How to recover requirements nobody wrote down
Do not rush the next hire
The pressure after a disappearance is to hire someone new immediately. Resist it for a few days. A new developer who starts with no inventory and no written requirements is set up to repeat the same story, and a careful one will ask for the documents above anyway. Having them ready also makes every quote you receive comparable.
Finish, or start again?
Once you know what exists, the decision gets much smaller. A system that runs, can be explained, and covers most of what was promised is usually worth finishing. A system that only half exists, with the hard problems still ahead, may be cheaper to rebuild. We wrote down the four questions we use to make that call.
Rescue or rewrite: the four questions
Make sure it cannot happen twice
Whatever you decide, set up the next engagement so your company owns everything from the first day: the repository in your company's account, hosting and domain in your name, credentials in a password manager you control. Then a developer leaving is an inconvenience instead of an emergency.
What client ownership means in practice
Software project rescue and takeover
If you are in the middle of this right now, start with the access list today. It costs nothing and protects everything else. If you would like someone to look at what exists with you, the intro call is 30 minutes with Alexandru, and you can bring whatever you have.