A developer handover squeezed into a few days is often incomplete. The code itself is usually the smallest part of what needs transferring. The larger problem is knowledge that lives only in the departing developer's head: why a specific workaround exists, what the one manual step is before every deployment, which environment variable has a value that nobody wrote down. A structured handover checklist forces that knowledge into documents before the developer's last day.
What Happens Without a Proper Developer Handover
The immediate consequence is usually a broken deployment. The new developer or contractor does not know the deploy sequence, misses a step, and causes an outage. The second consequence comes weeks later: a bug appears in a part of the system that has no documentation, and nobody can debug it without either reading several thousand lines of undocumented code or contacting the previous developer - who may not respond.
If your developer left without notice, the situation is worse. What to do when a developer disappears covers the emergency steps. This article is for the planned case - a resignation with notice - where you have time to do it properly.
The Developer Handover Checklist
Access and credentials
- All repository access transferred to a company-owned account, not a personal one
- Every third-party service account (hosting, database, email, payments, analytics) listed with login method
- API keys and secrets documented in a password manager or secrets vault - never in a README
- Domain registrar and DNS access confirmed - who owns the domain and who can change the nameservers
- SSL certificate renewal process documented, with the renewal date
- Two-factor authentication on critical accounts moved to a company-owned authenticator app or phone number
Codebase and architecture
- README updated with a current description of what the app does and how to run it locally
- Architecture diagram or written description of the main components (frontend, backend, database, third-party integrations)
- List of all external services the app depends on, with links to documentation and current usage levels
- Known technical debt documented - not just what it is, but why it exists and what the risk is of leaving it
- Any non-obvious deployment steps written out as a step-by-step runbook, not just 'push to main'
Environment and deployment
- All environment variables listed with descriptions and which environment (dev, staging, production) they apply to
- Hosting provider and deployment method documented (Vercel, AWS, Docker, manual - and specifically how it is triggered)
- Staging environment confirmed to exist and to be accessible by the incoming developer
- Database backup schedule confirmed, with the process to restore from a backup
- Any cron jobs, scheduled tasks, or background workers documented with their schedule and what they do
- Current spend on infrastructure and any pending billing or contract renewals
Ongoing work and context
- Current sprint or task list, with status on any in-flight work
- Any known bugs or issues that are not yet fixed, with severity and how to reproduce
- Client or stakeholder contacts and the communication channel each prefers
- Any pending vendor renewals, contract negotiations, or decisions that are in progress
- Anything the departing developer would want their successor to know that does not fit into any other category
How to Run the Handover
The best handover format is a walkthrough session, recorded if the incoming developer agrees. The departing developer shares their screen and talks through the codebase, the deployment process, and any non-obvious details while the incoming developer asks questions. This captures tacit knowledge - things the departing developer would not think to write down because they are obvious to them - that never makes it into written documentation.
If a direct session is not possible, a Loom video walking through each section of the handover document is a reasonable substitute. The incoming developer watches it, notes the gaps, and asks follow-up questions via email or message. The key is that the handover is interactive in some form, not just a document dropped in a shared folder.
What Incoming Developers Actually Need in the First Week
In the first week, the incoming developer needs to be able to run the app locally, make a small change, deploy it to staging, and confirm it works. If they cannot do those four things without help, the handover is incomplete regardless of how many pages of documentation exist. Use this test as the acceptance criterion for the handover.
The second thing they need is to understand what they should not touch yet. Every codebase has parts that are fragile, poorly documented, or recently changed in ways that are not fully settled. A list of "here is what to be careful about" is more valuable in the first month than a comprehensive architecture diagram.
What Most Handovers Miss
Even well-intentioned handovers tend to miss three things. The first is the ops layer: what happens when a background job fails at 2am, which alert fires, and what the person who receives the alert is supposed to do about it. If no one has written this down, the answer is: nothing, because no one knows there is a problem.
The second is the list of things that are broken but tolerated. Every codebase has them - a payment webhook that occasionally silently fails and requires a manual retry, a report that takes twelve minutes to generate because of a missing index that nobody has gotten around to adding. The departing developer has learned to work around these. The incoming developer will spend weeks discovering them by accident.
The third is vendor relationships. Who is the contact at the payment provider when chargebacks need disputing? Which account manager at the infrastructure provider has the direct line for an outage? This is soft knowledge that matters the first time a real problem happens, and it is almost never in any documentation.
When You Are Inheriting a Project With No Handover
If the handover did not happen and you are now the person trying to make sense of an unfamiliar codebase, the process is closer to a code audit than a handover. Taking over a project from another developer covers that process. It takes longer, costs more, and carries more risk than a structured handover - which is exactly why it is worth running the checklist above even if it feels like overkill when the developer leaves.
If you have inherited a project in this state and need help assessing what you have, get a rescue and launch review of your app. If the project has little documentation, no access to the deployment pipeline, or no working local environment, the sooner an honest assessment happens, the cheaper the recovery.
Common questions
What should a developer handover include?
Cover access and credentials, codebase and architecture, environment and deployment, and ongoing work. That means company-owned repository access, documented secrets in a vault, an updated README, environment variables, a deployment runbook, backup process, known bugs and vendor contacts.
How do I know a developer handover is complete?
The incoming developer should be able to run the app locally, make a small change, deploy it to staging and confirm it works, all without help. If they cannot do those four things, the handover is incomplete however much documentation exists.
What if I inherited a project with no handover?
Treat it more like a code audit than a handover. It takes longer, costs more and carries more risk. If there is little documentation or no pipeline access, an early honest assessment is cheaper, and Zovintra offers a rescue and launch review for this.
