Our developer has gone: what to do in the first week

The person who built your system has left. Perhaps it was a freelancer who took a permanent job, a small agency that wound down, or a member of staff who handed in their notice a month ago. The system still works. People still use it. But you have just realised that nobody is looking after it, and you are not sure who would know what to do if it stopped.

Many organisations find themselves here, and it is fixable. The first week is not about fixing anything. It is about finding out what you have, securing the basics and writing it down, so that every decision after that rests on facts rather than guesses.

Day one: do nothing to the system

The most useful instruction is the hardest: do not change anything yet. No updates, no clean-ups, no "quick tidy" of the server. Software that has run quietly for years may depend on settings nobody remembers. A well-meant change made without understanding is how a working system becomes a broken one.

You also do not need to panic. A system that worked yesterday still works today. You have time to be methodical.

Days one to two: find out what it is

Start with plain questions, and write down the answers as you get them:

• What does it do for the business? In one sentence, in the words of the people who use it.
• Who uses it, and how often? Staff, customers, suppliers, the finance team at month end?
• What depends on it? Does it feed the accounts, send emails, take payments or connect to another system?
• What happens if it is unavailable for a day? For a week? This tells you how much care it deserves.

Talk to the people who use it every day. They often know more about how the system really behaves than any document does.

Days two to four: secure the basics

Now find out who holds the keys. These are the questions that cause the most trouble when nobody can answer them:

• Who has the passwords and accounts? Administrator logins for the application, the server, the database, the domain name and any third-party services. If they are in one person's head or one departed person's email account, that is the first thing to fix.
• Where is it hosted? In your own premises, with a hosting company, or in a cloud account? Whose name is the account in?
• Who pays for it? Hosting, domain renewals, certificates and licences all expire, and the reminder emails may be going to someone who has left.
• Is there a backup, and has anyone restored one? A backup that has never been tested is a hope rather than a safeguard. Ask for evidence of the last successful backup, and for a restore to be tried somewhere safe when the time comes.
• Are the leaver's own accounts closed? Check that access for the person who left, and for any contractors they used, has been reviewed. Do this carefully, though, in case the system itself runs under one of their logins.

You are not changing the system here. You are building a list of what exists and who controls it.

Days four to five: find the code

The source code is the written form of your system. If you own the software, you should be able to get hold of it. Check your contract, though: if a freelancer or agency wrote it, paying for it does not by itself make you the owner of the code, and the handover is much easier if the contract says it does. Ask where it lives: a source-control service such as GitHub or Azure DevOps, a folder on the developer's laptop, or a copy on the server.

If you find it, ask someone technical, or an independent engineer, to check one thing: can it be built into a working copy of the system, away from the live one? If it can, you are in a far stronger position. If the code is missing, or does not match what is running, that is important to know now. It does not have to be a disaster, but it changes your options.

End of week: one page

Pull everything into a single page. It does not need to be elegant. Include:

• what the system does and who relies on it
• where it is hosted and who pays for it
• who holds each login, and where the passwords are kept securely
• where the code is, and whether it has been checked
• the state of backups
• anything you do not know

The last item matters most. A page that says "we do not know X" is more useful than silence, because it shows you exactly what to ask next.

Decide who owns the risk

Within the organisation, someone should be named as responsible for this system: not to look after it technically, but to make sure somebody does. In many organisations that is the operations director or finance director. Give it a name, put it on the page and tell the board or owners it exists.

This also answers questions that auditors, insurers and customers are likely to ask sooner or later: who looks after this, and what happens if it fails?

When to ask for an independent view

You can do the first week yourself, and most of it needs no technical knowledge. At the end of it, you will probably want an independent opinion on three things: whether the code and hosting are in a healthy state, whether anything is out of support, and what you would need in place to look after the system properly.

That is the job a software health audit is built for. It looks at one system, tells you plainly what condition it is in, and sets out a sensible order of work. It also gives you an informed view before you choose a supplier, whether that is us or someone else.

If you are already planning for the next time, a handover checklist for when a developer leaves, which we will cover in a later article, is the preventive version of everything above.

A sensible first step

Start by asking one person to find out who holds the administrator logins for the system, and where it is hosted and paid for. Those two answers resolve the largest share of the early risk, and they take an afternoon. Then start the one-page summary.

If you would like an engineer to look at your system, a software health audit is a good place to start. If the system needs someone to look after it month by month, that is what our software care service is for.