The Handover Doc Template I Give Every Collaborator

The first time I handed a project to someone else, I spent two hours answering questions over chat. The second time, I wrote a one-page doc and answered zero. That page is now the only thing I give a collaborator before they touch my work.

Here's the structure, section by section, plus the stuff I deliberately leave out.

Why One Page, And Why It's Fixed

A handover doc fails when it tries to be a manual. Nobody reads a manual before doing a task. They skim, they guess, and then they message you anyway.

So I cap mine at one page. If it doesn't fit, the project is too tangled to hand off cleanly, and that's a signal to fix the project, not the doc.

The second rule is that the sections never change. Same five headings every time, same order, across every project. That consistency matters more than it sounds. When someone picks up their third handover from me, they already know where "access" lives. They jump straight to it. No hunting.

I tried the flexible version first. Each doc had whatever felt relevant that day. The result was that every doc looked different, so people read every one from the top like it was new. The fixed template turned reading into scanning.

The five headings are: Purpose, Current State, Access, Next Action, Who To Ask. That's it. I'll walk through each one.

A quick note on when I write it. I don't write the doc when I start a project. I write it the day I hand it off. A doc written in advance describes a plan. A doc written at handover describes reality, and reality is the only thing the next person needs. The plan has usually drifted by then anyway.

This fits the wider habit I keep around solo operations. If you want the deeper context on how I keep things moving week to week, see The Weekly Operating Rhythm That Keeps a Solo Studio Shipping.

The doc lives next to the work. Not in a separate wiki, not in a pinned chat message. It sits in the project folder as a plain markdown file called HANDOVER.md. When the work moves, the doc moves with it. A doc in a different system than the work it describes rots in about two weeks, because updating two places is one place too many.

One page, five fixed headings, written at handover. That's the whole frame.

The Five Sections, One At A Time

Purpose comes first and it's two sentences max. What is this project for, and who is it for. Not the history, not the roadmap. Just "This tool generates product mockups for the shop listings. The audience is buyers browsing on mobile." If a collaborator reads nothing else, they should know whether they're about to do the right thing.

Current State is the honest paragraph. What works, what's half-done, what's broken. I write this bluntly. "The export button works. The batch mode is 70 percent done and crashes on files over 40 pages. The settings page hasn't been styled yet."

No optimism, no spin. The next person is going to find the broken parts in ten minutes regardless, so I'd rather they find them in the doc first.

Access is the shortest section and the one people need most. Where's the code, where's the deployed version, what accounts do they need. I list locations and account names here, never the secrets themselves. A line reads "Shopify admin, account is studio@, password in the vault." The next person knows exactly where to go.

If you're handing off anything that touches a storefront, this is where a line about Shopify access saves the most time, because that's the login people fumble with first.

Next Action is a single task, phrased as a verb. "Finish the batch mode crash fix, start with the file size check in the upload handler." Not a backlog. One thing. The moment someone knows the one next move, they stop asking "so what do I do now" and start doing it. If there are five things, I pick the one that unblocks the other four and name only that.

Who To Ask is the escape hatch. For most of my work the answer is me, and I put my preferred channel and my rough response window. But sometimes it's a specific past decision thread or an external doc, and I link that instead. The point is that the collaborator always has a next move when they're stuck, which means they never sit frozen waiting.

Five sections. Each one answers a question people used to ask me by message.

What Stays Out On Purpose

The leaving-out is harder than the putting-in. Every instinct says add more context so they're fully prepared. That instinct is wrong, and it's the thing that bloats a one-pager into a five-page document nobody finishes.

Secrets stay out. No passwords, no API keys, no tokens in the doc itself. The doc gets shared, forwarded, and sometimes committed to a repo by accident. I point to where the secret lives and keep the secret somewhere access-controlled. This isn't paranoia. It's just that a doc is the wrong container for anything you'd be upset to see leaked.

My opinions stay out too. The doc records what the project is and where it stands, not what I think about it. "I never liked this architecture" is a thought for a conversation, not a line in a handover. It biases the next person before they've formed their own read, and half the time they'd have made a better call without my grumbling in their ear.

The full history stays out. Nobody handing off needs the eight pivots the project went through. They need the current state. If a past decision genuinely affects the next move, I link the decision thread from the Who To Ask section and leave the rest buried. History is available on request, it just isn't in the way.

Roadmaps stay out. The doc has one next action, not a quarter of plans. Plans change the week after a handover anyway. I covered the architectural side of keeping things lean in The One Dependency I Refuse to Add to Any RAXXO Tool, and the handover doc follows the same logic: fewer moving parts, less to maintain.

Tooling tutorials stay out. If the collaborator doesn't know how to run a build command, that's a skill gap, not a handover gap. The doc tells them which command, not how commands work. Mixing the two turns every handover into onboarding.

The test I use: would this line still be true in a month? If the answer is no, it's probably a plan or an opinion, and it doesn't belong.

How I Keep It From Going Stale

A handover doc is only useful if it's true. The fastest way to lose a collaborator's trust is a doc that says the export button works when it crashed two days ago. After one of those, they stop reading the doc and start messaging you, which is the exact problem the doc was meant to solve.

My rule is simple. I update the doc at handover, and basically never otherwise. I don't keep it perfectly current during active work, because during active work I'm the one doing the work and I don't need to tell myself anything. The doc wakes up the moment it's needed and sleeps the rest of the time.

When I do update it, I rewrite from scratch rather than editing. Rewriting a one-pager takes about ten minutes, and it forces me to look at the real current state instead of patching an old version that's half-wrong. Editing invites you to leave stale lines in because they look fine. A rewrite has no stale lines by definition.

I date the top of the doc. One line: "Last updated 2025-02-14." If a collaborator sees a date three months old, they know to verify before trusting it. A date is cheap insurance against a doc that quietly aged out.

For anything scheduled or recurring, like social posts going out through Buffer, I note the cadence in Current State rather than the individual posts, because the posts change daily but the cadence holds for months. Write the thing that stays true.

The real test of a handover doc is whether the collaborator comes back with questions. Zero questions means it worked. Two or three means a section was thin, and I note which section and fix the template for next time. Over maybe a dozen handovers, that feedback loop tightened the five sections into what they are now. The template itself got handed off and improved, which is the point of writing templates at all.

Background: The Settings Page Every RAXXO Tool Gets Before Launch goes through the same consistency logic applied to a different artifact.

Bottom Line

Start with the five headings and nothing else: Purpose, Current State, Access, Next Action, Who To Ask. Write it the day you hand something off, not before. Keep secrets and opinions out, keep locations and the one next move in. Cap it at a page, and if it won't fit, that's your project telling you it's too tangled.

The payoff isn't the doc. It's the silence afterward. The collaborator picks up the work and just starts, and your inbox stays quiet. That quiet is worth more than any amount of extra documentation would ever buy you.

If you want to see how this fits into a repeatable solo operation, the Claude Blueprint lays out the system the handover doc plugs into. Steal the five headings, drop them in a file called HANDOVER.md, and use them on your next handoff. You'll feel the difference the first time someone doesn't ask you anything.

This article contains affiliate links. If you sign up through them, I may earn a small commission at no extra cost to you. (Ad)