Your developer left: what happens to your software?

One day the developer stops answering emails. Or the agency announces it is closing. Or the only person who understood the system retires or moves to another company. The application keeps running for now — invoices go out, orders come in — but nobody knows any more how it works inside, or what happens when something breaks.

This is more common than most people think, and usually it is not a disaster. It becomes one when the wrong decisions are made in the first few weeks. Below is the order I recommend when you find yourself in this position.

Step one: secure the access

The biggest risk is not that the code is bad. The biggest risk is that you do not control it. Before anything else, make a list and check whether each of these is in your hands:

• The code repository (GitHub, GitLab, Bitbucket or similar) — whose account is it on, and do you have owner or admin rights?
• The server or hosting — whose name is on the contract, who pays the invoices, do you have SSH or control panel access?
• The domain — who is the registrant and when does it expire? An expired domain is the fastest way to take a service offline.
• The database — where is it, and do you have a username and password?
• External services — email sending, payment provider, cloud storage, API keys. Many of these are registered to the developer's personal email address.

If you can still reach the developer, ask for every credential to be handed over now, not "when there is time". If you cannot, start with what is in your company's name — registrars and hosting providers will generally restore access to the owner once ownership can be proven.

Step two: take a backup before touching anything

Once you have access, take a full backup: code, database, uploaded files and server configuration. Not because something is broken right now, but because over the next weeks someone will start working inside the system — and you will need to know what it looked like before.

Also check whether automatic backups are made at all, and where they go. It often turns out that backups went to the developer's own machine, or quietly stopped a few months ago.

Step three: don't panic-rebuild

The first reaction is often: "Let's rewrite the whole thing from scratch, then at least everything is under our control." That is almost always the wrong first move.

A working system contains years of accumulated business rules, exceptions and fixes that no specification describes. Rewriting means rediscovering all of them — usually only after something has already gone wrong. Meanwhile the old system has to keep running with nobody looking after it.

A more sensible order: first make the existing system stable and understandable, then decide whether it is worth developing further or replacing piece by piece.

How I take over an unfamiliar codebase

I have worked on web projects since 2014 and have restored applications more than ten years old, in both the public and private sector, whose original developers were long gone. The work always follows the same order.

1. Audit. I go through what the system is made of: language and frameworks, their versions, the database, server configuration, external dependencies. I find out what is outdated, what is a security risk and what works well.

2. Documentation. I write down how the system is built, how to run it and where everything lives. That document stays with you — next time nobody has to start from zero.

3. Getting it running locally. Before changing anything, I get the system running in a separate environment that does not touch real users. That is the only way to try changes safely.

4. Small, safe fixes first. The first changes are deliberately small: security updates, the most urgent bugs, getting backups in order. Every change is traceable and can be rolled back.

5. Only then the bigger steps. Once the system is stable and understood, we can talk about moving components to new versions and adding new features. In earlier projects, exactly this order is what allowed the business functionality to be preserved in full and new features to be built on top.

If the application runs on a Linux server, I can take over server management too — the server setup is often just as undocumented as the code. If the server itself needs replacing, there is a separate post on server migration without downtime.

Warning signs that it is more urgent

Sometimes you cannot wait. Get someone to look at the system quickly if:

• the server's operating system or the framework is out of support and no longer gets security updates;
• the domain or certificate expires in the coming weeks;
• there are no backups, or a restore has never been tested;
• the system has started slowing down or occasionally stopping "by itself";
• nobody knows where the source code is — only the version running on the server exists.

The last one is harder, but there is a way forward from it too. For the wider risks of outdated components, see the risks of an un-updated WordPress — the principle applies to every platform.

How to avoid this next time

Once the system is back under control, three things are worth putting in place: all access is in the company's name, not a person's; the code lives in a repository that at least two people can access; and there is a short document on how to run and restore the system. It costs little, and the next change of developer is no longer a crisis.

Write to me

If your developer is gone and the system still runs but nobody dares touch it, describe your situation in a couple of sentences here — I reply within one working day and tell you honestly whether and how I can help. Signing an NDA is normal for me, so you can show the code and data without worry. If you would rather just talk, other ways to reach me are on the contact page.

Can you take over the system if there is no source code?

Often yes, but it depends on the technology. Some applications (PHP-based ones, for example) run on the server as source code, so the code is effectively there. Compiled applications take more work. I check this during the audit.

Do I have to decide right away whether to rewrite?

No. First the system needs to be made stable and understandable. The decision between developing it further and replacing it is much easier once you know what is inside.