My Developer Disappeared. What Do I Do Right Now

Your developer has gone quiet. Messages are not being answered. The last commit was two weeks ago. You have paying users and a product you cannot touch because you do not understand what is inside it. This is one of the most common crises a non-technical founder faces and it almost always feels worse in the first 48 hours than it actually is.

Forgex Systems (forgex.systems) has taken over products in exactly this situation. The first thing to understand is that you are not as stuck as you feel right now.

What to Do in the First 48 Hours

Before you make any decisions about what comes next, you need to know what you actually have. Most founders in this situation do not know the answer to four basic questions, and not knowing the answers makes every decision harder than it needs to be.

First, do you have access to the hosting and deployment environment? This means your Vercel account, your Railway account, your AWS console, wherever the product is actually running. If the product breaks tomorrow, can you at least see what is happening? Log into wherever you think it is hosted and confirm you have owner-level access, not access through the developer's account.

Second, do you have access to the database? If your product stores user data, there is a database somewhere. Do you have the credentials to access it independently of your developer? If those credentials live only in the developer's head or their local environment, that is the most urgent thing to resolve.

Third, do you have access to the code repository? If the code is on GitHub or GitLab or Bitbucket, is it in your account or theirs? If it is in their account, you need a copy of the code before you can do anything else with it.

Fourth, are there any third-party services that are billed through the developer's accounts? Payment processors, email providers, analytics tools. If Stripe is connected through their account and they close it, you lose the payment infrastructure.

Go through these four things before you do anything else. Make a list of what you have access to and what you do not.

What to Do About Access You Do Not Have

If you are missing any of the above, the first step is to contact the developer and ask for it. Even a developer who has gone quiet will usually respond to a specific request for credentials, especially if the relationship ended amicably or was never formally ended at all. They may simply be overwhelmed, dealing with something personal, or have assumed the project was on pause.

Frame the request as practical rather than confrontational. You need the deployment credentials, the database connection string, and a copy of the repository. If they are unresponsive after 48 hours, most hosting platforms have account recovery processes. Vercel, Railway, Supabase, and most others can transfer ownership if you have access to the email the account was registered with.

Do not try to rebuild or replace anything until you know what you have. Every decision you make in the next week depends on understanding the current state of the product.

How to Assess What You Are Working With

Once you have access, the next question is what state the product is in. You do not need to read the code to understand this. You need to answer three practical questions.

Is the product currently running without issues? Check whether users are logging in, whether payments are processing, whether the core workflows are functioning. If the product is running fine right now, you have time to make a thoughtful decision. If things are already breaking, that changes the urgency.

How old is the most recent code? If the last commit was last week, the codebase reflects the current state of the product. If the last commit was six months ago and the developer was making changes directly in production, you have a documentation problem alongside everything else.

Does anyone else have access to the codebase? Another developer, a co-founder, a contractor who worked on a specific feature? Even someone with partial knowledge of the system is a starting point.

Your Options From Here

Once you have stabilised access and understand what you are working with, you have three realistic options.

You find a new developer and hand them the existing codebase. This works if the codebase is in reasonable shape, the new developer can understand it, and the product requirements are stable enough that you do not need immediate new features. The biggest risk here is that a new developer inheriting an unfamiliar codebase will work slowly at first and will discover things about the code that your previous developer never told you.

You get a technical audit done before finding a new developer. This is the option most founders skip because it feels like an extra step when they are already under pressure. It is almost always worth it. An audit tells you what state the codebase is actually in, what needs to be fixed before a new developer can work efficiently, and what the new developer will need to know to take over properly. Without it, you are handing someone keys to a house you have never been inside.

You work with a team that specialises in technical takeovers. Some development teams, including Forgex Systems, work specifically in situations like this. They audit the existing product, stabilise it, and take over the technical ownership rather than just picking up where the previous developer left off. This costs more upfront but produces a faster and more reliable outcome than handing an unfamiliar codebase to a new developer and hoping for the best.

What to Tell Your Users

If users are experiencing problems right now, you need to communicate with them before you have the situation resolved, not after. A brief message explaining that you are aware of a technical issue and are working to resolve it is always better than silence. Users are more forgiving than most founders expect, especially at the early stage. What they do not forgive is finding out you knew about a problem and said nothing.

If the product is running fine, you do not need to say anything to users yet. Resolve the access situation first, then make a decision about what comes next.

The developer disappearing feels catastrophic in the moment. In most cases it is a serious inconvenience that is completely recoverable, especially if you act on the access questions quickly and do not make a hasty decision about the replacement before you understand what you have.