What to do if your only developer leaves your company

Your only developer hands in their notice. Nobody else in the building can read the code, and in four weeks the person who knows how everything works will be gone.

This is a different problem from a supplier disappearing, and in one important way it is a much better one: you have notice. Whether that notice period is worth anything depends almost entirely on what you ask for in the first week of it, and most businesses spend the first week being surprised.

The notice period is the whole asset#

Treat it as a handover project with a deadline, not as four weeks of business as usual.

The instinct is to get as much delivered as possible before they go. That is almost always the wrong call. Half-finished work by somebody who is leaving becomes somebody else's archaeology, and the feature you squeezed out is worth far less than the ability to keep the system running for the next two years.

So the first conversation is about what gets written down, not what gets built.

Ask for these, in this order#

Access, in your name. Every account the system touches: domain registrar, DNS, hosting or cloud, code repository, database, payment provider, email sender, error tracking, analytics, app store listings. Not shared with you. Transferred, with your company as the owner and your billing details on it.

A run-through, recorded. Sit with them and screen-record the walkthrough: how the system is deployed, what runs on a schedule, what breaks most often and what they do about it. An hour of screen recording is worth more than any document they will write under time pressure, because it captures the things they would never think to write down.

Someone else deploying, while they watch. This is the single highest-value hour of the whole notice period. Have a colleague, or an outside developer, do a real deployment start to finish with the leaver in the room saying nothing unless something goes wrong. If it only works when they do it, you have not got a handover, and you want to discover that now rather than in November.

The list of what is needed, not the secrets themselves. Which API keys and credentials the system requires and where they live, so that when one expires you know what it was for.

The undocumented decisions. Ask specifically: what in here would surprise a new developer? Every system has three or four things that look wrong and are right for a reason nobody wrote down. That question, asked directly, is the fastest way to get them.

Do not ask them to write documentation#

Or rather, do not rely on it.

Documentation written in a notice period by somebody with one foot out of the door is thin, and the parts you actually need are the parts they no longer notice, because to them it is obvious. You will get a README describing the folder structure and nothing about the cron job that would take the business down.

Recordings and a watched deployment get you further, in less of their time, and they are honest about what you did not capture.

Say something to them, and mean it#

People leaving are usually more helpful than employers expect, and much more helpful when the relationship stays decent. A leaver who is treated well will take a phone call in six months and tell you in ten minutes what would otherwise take a fortnight of reading.

It is worth asking, explicitly and warmly, whether they would be willing to answer the odd question after they go, and worth agreeing how that works, whether it is a favour or a paid arrangement. Get the personal email address. Do not make it awkward.

Then get it read, before you hire#

The reflex is to recruit a replacement immediately. It is worth waiting a beat.

Before you know what the system actually needs, you do not know who to hire, or whether you need to hire at all. A codebase audit by somebody outside gives you a written description of what you have, what state it is in and what keeping it running actually takes, and it usually takes days rather than weeks.

That document changes the hiring conversation completely. You can show it to candidates, which makes you a serious employer rather than a mystery, and it tells you honestly whether this is a full-time role or fifteen days of work a year. Plenty of businesses with one developer discover they had a part-time need and a full-time salary.

Cover the gap without panicking#

Between your developer leaving and whatever comes next, somebody needs to be able to keep the lights on. That is a smaller requirement than it feels: usually the ability to respond if something breaks, apply security updates, and make the occasional small change.

That is a very different job from taking over the system permanently, and it can be bought by the job rather than as a commitment. The point is to remove the deadline pressure from the hiring decision, because hiring in a hurry because nobody can fix anything is how businesses end up with the wrong person for two years.

What we do#

We do exactly this work: reading systems whose author has left, writing down what is there, and keeping them running while a business decides what it wants.

The read comes first and is a fixed price agreed before it starts. You get a written description of what you have and what it would take to carry on, including the case for hiring rather than using us, which for some businesses is the right answer and we will say so.

Everything is in your name from the first day. On the code we keep the copyright and you hold a perpetual licence to use it for your project, change it, and have anybody at all change it, with us or without us. So when you do hire, they pick it up and carry on, and nothing has to be unpicked first.

The version of this article you want to read is the one before it happens. If you have one developer and no plan for the week they resign, the list above is worth doing now, while nobody is leaving and everybody is relaxed.