How to run a technical handover session: the one-hour agenda, what to record, and what to ask before the developer leaves

First item on the agenda: the developer ships a one-line change to production while you watch and write down every step. That is how to run a technical handover session: about 60 recorded minutes (my working rule) on a fixed agenda, ending with follow-ups, each with a name and a date, before the person who knows the system leaves.

How to run a technical handover session in one hour: what it is, and the agenda

A technical handover session is a recorded hour in which the person who knows the system operates it in front of the person who will own it: a live deploy, the diagram and what breaks most, the accounts and keys, a restore, twelve questions, and the follow-ups written down with names and dates.

If your question is what does a developer handoff look like from start to finish, this hour is its live half. The documents the session walks through are the ones on the software project handover checklist, and they should exist before the hour starts.

One boundary, so the two halves do not blur. When a new developer arrives, the founder schedules working sessions for them: trace a request, deploy a harmless change, find it in the logs and roll it back, trigger a test error, restore data, change someone’s access. That task list belongs to my guide on what to give a developer taking over your app. This page is the single recorded hour with the person who is leaving, so the agenda below does not walk through that list item by item.

The split below is my working rule, and the minutes are approximate. Start the recording before the first item and stop it after the last.

Three of the blocks lean on documents of their own. The diagram block draws on how to create architecture diagrams. The accounts block is the core of owning an app someone else built. The restore block goes faster when the steps already sit in a runbook template, because the developer reads them aloud and you watch whether they still match the system.

Record the handover session and keep its follow-ups in one register: those two things are what the hour leaves behind. Questions that come up after the developer has finished go into the same register, and my rule is to agree the answer window (how many days, and through which channel) before the session ends, while everyone is still in the room.

On the Production Hardening Sprint, the live technical handover is deliverable 13.4: we conduct and record a 60-minute walkthrough with the client team and technical advisors.

What goes wrong without it

Each row is a situation a skipped or rushed session leaves behind, and what the hour would have left in its place.

The first row has a name, a bus factor of one: the knowledge lives in one head, so every holiday, notice period or sick day pauses changes to the app. The fourth row is why the session is live rather than another document; the same phrase is also used about AI models whose decisions nobody can trace, which is a different subject.

My audits from June and July 2026 scored the Maintainability & Evolvability pillar on all 21 third-party apps, and it averages 61.1 out of 100. Those 21 are the public and held-out third-party apps I audited, a set I chose rather than a random sample, so the average describes them and is not a rate for AI-built apps in general.

A developer gives notice and hands over a document listing the repository, the host and the database. Weeks after they leave, a job that ran on a schedule stops, and nobody at the company knew it existed, because no one had asked what runs on a schedule and where. Documentation is more useful when the team can ask questions about operating the system, and in that case nobody did. The lesson I take from it: the question nobody asked in the session is the one that costs the most later.

How to prepare, record and follow up

Preparation, recording and follow-up are three jobs: before the session, open the documents and print the twelve questions; during it, record the screen and the voice while the developer drives; after it, keep a register in which every open question has an owner and a date.

Before: the twelve questions to ask, and the documents to have open

Ask the developer to prepare the handover document before the hour, not during it, and to have it open when the session starts, beside the diagram, the runbooks and the account inventory. If no handover document exists yet, have them make one from the questions below: each answer becomes a section. Anything they create for the session, the handover document included, goes in a folder the company owns. If you end up having to write the handover document yourself, a good one names each thing the session will show, so the hour has a script.

The full list of what a handover document should include is the checklist’s job; the line I use is that the document lists and the session proves. Put the twelve answers in the handover document too, so the written record and the recording agree. For writing the documents themselves, how to write technical documentation goes through each one.

These twelve are my working list, in the order I would ask them. Print them, and tick each one as it is answered or moved to the register.

1. 01 How do I deploy, and how do I undo a deploy?
2. 02 Where are the secrets, and who can rotate them?
3. 03 What breaks most, and what does it look like when it does?
4. 04 What runs on a schedule, and where?
5. 05 Which one query or job is slow?
6. 06 Which third party would take the app down if it went away?
7. 07 Where are the backups, and when was one last restored?
8. 08 Which accounts are in whose name?
9. 09 What did you mean to fix and never did?
10. 10 What would you not touch?
11. 11 Who else has ever changed this?
12. 12 What do I not know to ask?

The last question gives the developer room to name whatever the other eleven missed. Question four is the one that would have caught the scheduled job above. Question seven has two halves on purpose: a backup that has never been restored is an open row in the register, not an answer.

During: how to record a code walkthrough video

The recording is what lets someone who was not in the room use the hour later, so it follows a few rules of mine.

1. 01 Record the screen and the voices, not faces: the screen is the evidence.
2. 02 Make one recording for the whole hour, with chapter markers or a written contents list with timestamps for the six agenda items.
3. 03 Let the developer drive and narrate while the owner asks the questions.
4. 04 Paste every command the developer types into the notes as well, so nobody has to copy it off a paused video.
5. 05 Store the recording with the documents in an account the company owns, never in the developer’s own account.
6. 06 Keep it a walkthrough of this system, not a tutorial on the language or the framework.

Loom’s help center says you can add chapters to any Loom “by adding a list of ascending timestamps and chapter titles”, and the chapters must start at 0:00. Its length rule matters more here: “Loom Starter users have a 5-minute recording duration limit”, so a one-hour session does not fit on Starter, while Loom Business, Business + AI and Enterprise “can enjoy unlimited recording time”. OBS Studio describes itself as “Free and open source software for video recording and live streaming”, and its Hybrid MP4 output format, added in version 30.2, takes chapter markers from an “Add chapter marker” hotkey. With OBS the owner can drop a marker as each agenda item starts; with Loom, the chapter list is typed in afterwards from the timestamps in the notes.

The tour of the repository a future developer watches before touching the code is a separate recording, and the subject of what is a codebase walkthrough; this hour is about operating the system, not reading it.

After: the follow-up register, and the answer window

Every question the session left open, and every question that arrives later, gets a row with a name and a date. The format is plain:

The answer window is a number of days and one channel, agreed before the developer’s last day and written at the top of the register; that is my working rule, and the exact number matters less than both sides having agreed it. The register closes when someone else can deploy, restore a backup and rotate a key without asking anybody.

If the developer has already gone, there is no session to record. The next developer runs the twelve questions against the code and the accounts instead, and every answer they cannot find becomes a row in the same register. I’d give their first two days to a legacy code takeover and, if the app will not start on their machine, to the steps for when you cannot run the project locally.

How to verify it

A technical handover is verified by someone who was not in the session: they ship a one-line change and restore a backup to a scratch database from the recording and the documents alone, and the time it took is written down. Every row of the follow-up register has an owner and a date.

Each of the four checks below leaves a piece of evidence you can point to later.

1. 01 The recording exists, opens for someone other than the developer, and covers all six agenda items. Evidence: its contents list or chapter markers.
2. 02 The supporting documents are the ones shown on screen, stored in the company’s account. Evidence: a link that opens for the owner.
3. 03 No register row is missing an owner or a date. Evidence: the register itself.
4. 04 Receiver test: a person who missed the session deploys a one-line change and restores a backup into a scratch or staging database, never over production, using only the recording and the documents. Evidence: their log of the attempt, with how long it took.

A slow receiver test is a finding, not a failure: every step where they had to stop and guess is a missing line in a document. The production readiness review is where all four pieces of evidence get read together.

On the sprint, deliverable 13.4 is verified this way: we deliver the recording, supporting documents, and answers or follow-ups from the session.

Technical onboarding for the developer who arrives next

Technical onboarding gives a new developer the tools, system access and knowledge to work on the system. After a handover it starts from what the handover left behind: the recording, the documents and the follow-up register. The twelve questions become the check that the newcomer can answer, and the first task is the one-line change the session opened with.

The founder’s side of it, booking the sessions, answering why rather than how, and handing the work over in order, is laid out under developer onboarding when there is no engineering team.

What the handover adds, in my reading, is a starting order. The newcomer watches the recording and reads the register before opening the code. Getting the project running locally comes next, as in the already-gone path above. Then they ship the same one-line change, and only after that do they answer the twelve questions without looking at the recording. Any question they cannot answer is a gap in the handover, and it goes in the register like any other. Technical onboarding in the IT-department sense, a laptop and accounts for a new employee, is a separate job.

Where the sprint does this

Beside the recorded handover sits a 20 to 30-minute recorded walkthrough of the repository, data model, and key architectural decisions (deliverable 10.9). After handover, there are 30 calendar days of async access for questions about the delivered architecture, operation, and safe future changes (deliverable 13.7). The production readiness report (deliverable 13.1) gives the result for every scope item; it accounts for all 123 IDs, keeps failures visible until resolved and explains genuine non-applicable items. Each of these appears with its verify step in the handover deliverables in the published scope.

Common questions about technical handover sessions

How to do a proper handing over?

For a running software system, a proper handover is a recorded session on a fixed agenda (a deploy, the diagram, the accounts, a restore, the questions, the follow-ups), the documents that session walks through, and a test afterwards that someone else can operate the system from them. Handing over office work or a shift is a different job.

What is the purpose of a handover?

In a technical handover, the purpose is to show that someone other than the leaving developer can operate the system: deploy a change, restore a backup and rotate a key without asking anybody. Once the developer has gone, the recording and the register are what keep that true.

What to say during a handover?

In a technical handover, the receiver does most of the talking by asking: how to deploy and undo a deploy, where the secrets are, what breaks most, what runs on a schedule, where the backups are and whose name each account is in. The developer answers by showing each one on screen.

How to write a good handover email?

For a software handover, the email is one paragraph: where the recording, the supporting documents and the register live, who owns each open question, and the answer window and channel agreed in the session. Send it on the day of the session, so everyone works from the same links.

How to write a good handing over note?

For a system, the follow-up register is the note: every open question, the person who owns it, the date it was asked, and where its answer will live. Free text buries open questions; a row with an empty answer column stays visible until someone fills it.