Sole developer left — what now?

The Slack message arrives on a Tuesday. The developer who built the system is leaving. They are giving notice and they are professional about it. Two weeks of overlap, documentation, an offer to be on call for emergencies for a while.

It does not help. You are looking at a system that still makes money, that you do not understand, and that no one else on the team has ever read. The first instinct is to find a replacement before they walk out the door. Resist it. The order matters.

What you actually own right now

For about thirty days, you are the operator of a system you did not build. Some of what you own is obvious — the codebase, the database, the production server. Some of it is less obvious and matters more:

• Every credential that was in your developer’s personal email
• Every API key tied to their account on a third-party service
• Every cron job, queue worker, and scheduled task they set up and never wrote down
• Every assumption about how the system is supposed to behave that lives in their head

The system will keep running on momentum for a while. The risk is not that it stops. The risk is that something small breaks and you discover, in the moment, that you do not have access to the thing that fixes it.

The 72-hour list

Before anything else, do these. While the developer is still answering messages.

• Credentials inventory. Every account: hosting, DNS, registrar, GitHub or GitLab, payment processor, email service, monitoring, error tracking, analytics, every SaaS the system depends on. Who owns each? Is the owner the developer’s personal account or the company’s?
• Backups. Where are they? What is the retention? Has anyone, ever, tested a restore? Note the answer; do not test yet.
• The kill list. Which third-party integrations are billed against the developer’s personal card? Which APIs use a key tied to their email? List them.
• Domains and SSL. Who is the registrant of record? When does the domain renew? Is the renewal billed to a card that is still valid? Same questions for the SSL certificate, if it is not auto-renewed.
• Deploy access. Can someone other than the departing developer ship a fix? Document the actual command, the actual server, the actual repo branch. Not a sketch. The exact sequence.

Do not rotate any credentials yet. Inventorying them is enough for the first 72 hours. Rotation comes after you know what depends on what — otherwise you take the system down trying to make it safe.

For the agency-side version of the same playbook, the legacy handover checklist covers the access inventory in the format we use on takeovers.

The 30-day list

Once the immediate access risk is contained, the next month is about converting tribal knowledge into written knowledge before it walks out the door.

• Codebase map. Ask the developer to walk you (or a trusted technical person) through the entry points, the database, the deploy path, and the cron jobs. Record it. The transcript is more useful than the diagram.
• Architecture brief. One page. What the system does, what it integrates with, what depends on it. Written in language a future developer can read in ten minutes.
• Deploy runbook. The exact steps to ship a code change, including how to roll back. Tested by someone other than the departing developer before they leave.
• Incident playbook. What to do when the site is down, when payments fail, when the database is full. Even a one-page version is worth more than the zero-page version that exists today.
• First written README. Most legacy systems do not have one. The departing developer has, in their head, the answers to the first ten questions a new hire would ask. Capture them.

This is not a rewrite. This is not even a refactor. This is documentation. A weekend of focused recording at this stage prevents months of expensive guessing later.

What not to do

Three mistakes are common and expensive.

• Do not hire a replacement before the system is mapped. A new developer will ask “how does this work?” on day one and you will not be able to answer. They will then form their own model, which may or may not be right, and will quietly start changing things based on it. The map has to exist before the hire.
• Do not agree to a rewrite from anyone who has not seen the system. The fastest way to lose the next year is to take a rewrite quote from someone who has read the marketing site, not the codebase. The rewrite vs refactor essay covers the longer version of why this is almost always the wrong move at this stage.
• Do not roll credentials before you have inventoried what uses them. Rotating an API key looks like security; rotating one that is hard-coded in a cron job looks like an outage. Inventory first, rotate second.

When to bring outside help

There is a window where outside help is most useful: after the 72-hour list is done, before you have hired a replacement. In that window, an external operator can do the work the departing developer no longer has time for and the future hire is not yet there to do.

This is what our Handover service is shaped for: codebase map, architecture brief, deploy runbook, README, in writing, before the bus factor of one becomes a bus factor of zero. It pairs naturally with an audit when the system also has unaddressed runtime risk — and the signs your PHP system needs a refit are usually visible by the second week.

The point is not that you cannot handle this alone. The point is that the work has a shape, and the shape benefits from someone who has done it before. The cost is small compared to the cost of hiring the wrong replacement, agreeing to the wrong rewrite, or losing the documentation window entirely.

The quiet outcome

Thirty days from the Slack message, the system looks the same from the outside. It is still up. It is still making money. The website has not changed.

What has changed is that the bus factor is no longer one. The system has a written map. Credentials are inventoried. Backups are tested. The deploy path is reproducible by someone who is not the person who built it. A new developer can be hired against a known-shape codebase rather than a black box.

That is the quiet outcome. It does not look heroic. It looks like nothing happened. That is exactly the point.