Your Developer Just Quit. Here's Your Survival Checklist.

Breathe. Your developer quitting is not the emergency it feels like. The message lands, they’re out in two weeks, and it feels like the floor just went, especially if they were the only technical person you had. Here’s the part that’s true even though it doesn’t feel true right now: the person leaving is rarely what hurts you. What hurts you is everything that lived only inside their head and never got written down anywhere you can reach.

So before you spiral, understand the actual shape of the problem. A developer leaving is a knowledge-and-access event, not a code event. The code still exists. The product is probably still running right now. What is suddenly at risk is your ability to get into it, understand it, run it, and change it without the one person who is now on their way out.

The good news is that most of that risk is fixable in the next 48 hours, while the relationship is still warm and cooperative. The window closes fast. Let’s use it well.

The Real Risk Is What Lived in Their Head

Here is what makes it dangerous: almost everything critical about running a small product is invisible. It doesn’t live in the code. It lives in habits and memory: which command spins the thing up, which environment variable it breaks without, which service quietly sends your emails, which button you must never press on a Friday.

While your developer was around, none of that mattered, because you could just ask them. The moment they leave, that informal knowledge becomes the single most valuable and most fragile asset you have. It is not written down. It is not in the repository. It is in a human who is about to have other priorities.

This is why your job in the next two days is not to find a replacement. It is to extract, in a structured and permanent form, everything that currently exists only as your developer’s memory. Do that, and the departure becomes an inconvenience. Skip it, and the departure becomes the reason you spend three months and a small fortune rebuilding things that were working fine last week.

Your First 48 Hours, in Order

Do these in sequence. The order matters, because access unlocks everything else, and the handover is worthless if you can’t get into what they’re describing.

That is the whole emergency, handled. Notice that none of it is technical work you have to do yourself. It is you making sure the knowledge and the access are captured somewhere permanent before the only source of both moves on.

Stay Gracious. It Is Also the Smart Play.

You might be hurt. You might feel abandoned, especially if the timing is terrible. Feel it on your own time. In every message to the person leaving, be warm, be grateful, and make the exit easy.

This is not just decency, though it is that too. It is leverage, the good kind. A developer who leaves on genuinely good terms will answer a quick question three months from now when your new team hits something baffling. A developer who leaves angry, cornered, or accused will let that message sit unread, and you will never know what they could have told you in ninety seconds.

There is a version of this where you get anxious about access, start demanding things in an accusing tone, and turn a cooperative handover into a defensive one. Don’t. Ask for what you need calmly and in order, thank them for each thing, and let the relationship end as a relationship you could restart.

Stabilise, Then Fix the Real Point of Failure

Once the access and knowledge are locked down, the loudest instinct is to fill the seat immediately. Resist it. A hire made in week one, before you understand what you actually have, is usually the wrong person at the wrong scope, and undoing that is more expensive than the gap ever was.

Start with an honest look at your bus factor: the number of people who’d have to disappear before your product becomes unrunnable. It was one, and that’s how you ended up here. The job now isn’t just to survive this departure, it’s to make sure one human is never again allowed to be the only person who can deploy, the only one who understands the architecture, the only holder of the keys. That’s a structural risk that gets built quietly, over months, without anyone noticing, and the fix is just as unglamorous: keep ownership of code, deployment, domain, and services in accounts you control, treat documentation as a habit instead of a panic response, and make sure at least two people can run and deploy the product from day one.

While you decide, keep the product alive with almost no effort. A running product that nobody is changing rarely breaks on its own. Make sure you can see it: uptime monitoring, error alerts, and billing warnings so nothing lapses. Make sure the domain and hosting renew automatically on your card, not the departing developer’s. Know who to call for a genuine outage. That’s stability. It buys you the weeks you need to hire deliberately instead of desperately.

We got to test this on ourselves. The most important engineer on one of our teams, the person leading it, left. On paper that is exactly the scenario this article is about. It turned out to be a non-event. Our ways of working and the key decisions were written down in Confluence. Every discussion lived in Slack. Shared credentials and keys sat in a team password manager, Bitwarden, rather than in one person’s browser. He had made a habit of cc’ing the whole group on the emails that mattered. So when we took over the most important project he had been running, it was almost as if he was still there. There was no secret knowledge to reconstruct, because none of it had ever lived only in his head. That is the whole game: make the knowledge boring and visible, and a key departure becomes a calendar problem instead of a crisis.

Document as you go, too. Every question you ask, every answer you get, every login you find, write it down where the next developer will look. You are not just surviving this departure. You are building the handover you wish you’d had, so the next one is boring instead of frightening.

You will get through this one. The floor didn’t actually go. Capture the knowledge, secure the access, stay gracious, keep it running, and hire on your own timeline. Do those four things in order and a departure that felt like a crisis on Monday is a solved problem by Wednesday. If the 48-hour window is already closing and you’d rather not run it alone, this is most of what we do: step in when the technical person leaves and make sure the product, and everything they knew, ends up fully in your hands.