Your Only Developer Just Quit: The First 14 Days

Your only developer just gave notice, and now you have a two week countdown that decides whether your product keeps running or quietly falls apart the week after they leave. If you are asking what to do when a developer quits and there is no one else who knows the codebase, the honest answer is that most of the damage happens in the notice period, not after it. What you do in these 14 days determines how much of what is in that person's head makes it out before they walk out the door.

This is not a document you ask them to write on a Friday afternoon. It is a short, structured plan you run together, starting the day they give notice.

Day 1 to 2: lock down access before anything else

Before you talk about handover documents or knowledge transfer, get a clear picture of everything one person can currently reach. Most companies with a single developer never built a second admin account for anything, so the departing developer is often the only person who can log into half of the following:

• the domain registrar and DNS settings
• the hosting account or cloud provider console (AWS, Hetzner, DigitalOcean, whatever it is)
• the production database, including any read replica or backup service
• the CI/CD pipeline and any deployment keys tied to it
• the payment processor and its API keys
• the email sending service (transactional email breaks quietly and nobody notices for days)
• third party APIs the product depends on
• the source control host, especially who has admin rights on the repository
• the password manager or credential vault, if one exists
• any two factor authentication tied to a personal phone or authenticator app

Go through this list together and add a second person, ideally you or someone in a permanent role, as an owner or admin on each account. Rotate any credential that cannot be shared cleanly, such as personal API tokens, and generate a fresh set tied to the account you control. This step alone prevents the worst outcome: a locked out production environment three weeks after your only developer is gone and unreachable.

Day 3 to 5: write down how deployments actually happen

Ask your developer to walk you through, in writing, exactly what happens between "code is ready" and "code is live." Most small companies never wrote this down because one person did it the same way every time and never had to explain it. That knowledge needs to survive the handover even if you never touch a deploy yourself. At minimum you want:

• what triggers a deployment (a manual command, a merge to a branch, a scheduled job)
• where environment variables and secrets are stored, and who can edit them
• what a normal deploy looks like, including how long it takes and what "it worked" means
• any manual step that is not automated (a migration that has to run by hand, a cache that needs clearing, a service that needs restarting in a specific order)
• scheduled jobs and cron tasks, what they do, and what breaks if they stop running
• monitoring and alerting: where errors show up, and who currently gets notified

This is also the moment to ask the question most non-technical founders forget to ask: what breaks first if nobody touches this system for a month? The answer is often a specific dependency that needs renewing, a certificate that expires, or a batch job that silently stops after a data source changes shape.

The handover interview

Somewhere between day 3 and day 10, sit down for a structured conversation instead of hoping a document covers everything. A written handover misses the things a person did not think to write down because they seemed obvious, and those are usually the things that cause the next outage. Our guide on inheriting an undocumented codebase covers this from the other side, for whoever ends up reading that document later, but the interview itself is what fills the gaps a written handover leaves behind.

Ask directly:

• What is the part of this system you would not want anyone to touch without you in the room?
• What workaround or hack exists that nobody outside this codebase knows about?
• What is currently broken, half fixed, or being held together?
• Who else, outside the company, has ever touched this code (a former contractor, an agency, a previous employee)?
• If you got a call about this system a year from now, what would you guess the problem was?

That last question tends to surface the fragile parts faster than any documentation review. Record the conversation if your developer is comfortable with that, since a transcript catches detail that notes taken in the moment will not.

Build the open issues list

Before the last day, get a single, ranked list of everything currently open: known bugs, half finished features, technical debt the developer has been meaning to address, and anything flagged by customers that never made it into a formal bug tracker. Sort it by how much it will hurt if it goes unfixed for a month, not by how interesting it is to work on. This list becomes the starting point for whoever covers the gap next, whether that is a new hire, a fractional developer, or you triaging things yourself with outside help.

Days 6 to 14: freeze what you can, and decide who approves changes while the seat is empty

Once access is secured and the handover interview is done, the last week is about reducing risk rather than adding features. Two decisions matter here.

First, agree on a change freeze for anything non essential. New features can wait. Bug fixes that are actively hurting customers cannot, so decide now who is authorized to approve and ship an emergency fix once your developer is gone, and what that process looks like without them.

Second, decide who is watching the system day to day. Someone needs to check the error monitoring, confirm scheduled jobs ran, and notice if a certificate is about to expire. This does not need to be a developer, but it needs to be a specific person with a specific daily habit, not a vague hope that "someone will notice" if something breaks.

What to do after your developer quits and the 14 days are up

Fourteen days buys you a documented, access secured system and a ranked list of what needs attention. It does not buy you a developer. At some point in the following weeks you will need someone who can actually read the code, ship the fixes on that open issues list, and keep releases moving while you hire a permanent replacement.

This is exactly the gap interim coverage is built for: someone who can step into a system they did not build, work from the handover you just created, and keep it running without waiting for a six week hiring process to finish first. If that is the position you are in, our web application development team has done this kind of takeover before and can tell you honestly, before any commitment, whether interim coverage or a faster permanent hire makes more sense for your situation.

Reach out to hello@wolf-tech.io, or find more detail at wolf-tech.io. The first conversation costs nothing, and it is a lot cheaper than finding out what breaks when nobody is watching.