What a good handover looks like.

“You’ll own everything when it’s done” is the easiest sentence in this industry. Every developer says it, including the ones whose clients later pay $180 an hour to recover their own database. So I’m not going to say it. I’m going to show you the artifacts that make it true instead. Every file, account, and recording that changes hands when I finish a build, in the order you receive them. By the end you’ll also have a one-line email that tests any developer’s handover, mine included, before you’ve paid anyone anything.

§1The fire-me test

A handover is done when a competent developer you’ve never met can set up, run, deploy, and extend your system without emailing me. That’s the whole standard. Not “the code is on a USB stick somewhere.” Not “he seems reachable.” A stranger, your repo, no phone-a-friend.

I hold myself to this standard for a blunt reason: I’m one person. The software industry has a name for the risk of me: the bus factor. That’s the number of people who’d have to vanish before a project stalls. A solo developer is a bus factor of one, and no amount of charm changes that. What changes it is making the knowledge an artifact instead of a memory. Everything below exists so that my availability is a convenience, never a dependency.

You’ll notice this entry answers one of the two questions I get on almost every call: “what happens if you disappear?” The answer isn’t reassurance. It’s a list, and you can audit it.

You can even run the fire-me test before trusting it. When the build is near done, hire any independent developer for two hours. Give them read access to the repo and one instruction: get the system running from the README alone, and note every place you got stuck. Two hours of a stranger’s hourly rate converts the biggest promise on this site from a claim into a receipt. And if a developer ever objects to being tested this way, the objection is your test result.

The agency checklists that rank for “project handover” do agree on the completion standard, at least. Most define done as the new team running the project unaided. Where they lose you is scale. They’re written for CTOs receiving fifty-page transitions from other agencies, and you’re one owner receiving one system from one developer. The standard survives the shrinking. The bureaucracy doesn’t need to.

§2Owned from day one

The biggest handover decision happens at kickoff, not at launch. Everything starts in your name, so there is almost nothing left to transfer at the end. The code repository is created under your GitHub account, and I work in it as a collaborator you can remove with one click. The hosting account at Hetzner or DigitalOcean is opened in your name, on your card. The domain sits at your registrar. I never hold it, not even for a week of convenience.

This isn’t my private invention; even the agency-to-agency literature lands on the same rule. Simple Thread’s checklist, written by Justin Etheredge in 2020, says it plainly. Keep every client service “in their own accounts that can just be handed over.” The difference is that most shops treat that as advice for the exit. I treat it as the setup, because the mechanics matter. If I hold the accounts, the handover is a favor you request. If you hold them, it’s a permission you revoke.

Run the comparison against the last vendor you left. How many emails did it take? How many “let me check with the team” replies? Ownership that requires the other side’s cooperation is not ownership. It’s goodwill with extra steps.

For completeness, here is everything I do hold while the build runs. A collaborator seat on your repo. A login on your server. A development copy on my own machine. The development copy runs sample data, never your real records. All three exist to be deleted at the handover call. §6 covers the deleting.

§3What changes hands

Here is the transfer table for a typical build. The third column is what separates it from the checklists that rank for this topic. Most of it is yours long before the last invoice.

About the password row, because “I’ll send you the passwords” is where security usually goes to die. The keys move inside your password manager; 1Password and Bitwarden both do shared vaults. One entry per secret, each labeled with what it opens and what breaks if it changes. No spreadsheet. No email with credentials.xlsx attached. No chat message you’ll be scrolling for in 2029.

One edge case is worth knowing about, because it comes up in rescue projects that started under someone else’s account. GitHub has a formal transfer mechanism, and its documentation is specific about what moves. The issues, pull requests, wiki, webhooks, deploy keys, and full commit history all travel with the repository. Links to the old location redirect to the new one. The one trap in the fine print: those redirects are deleted permanently if a new repository is later created at the old address. So after any transfer, the receiving developer should repoint their local copies (one command, git remote set-url) instead of trusting the redirect forever.

Translated out of Git: even in the worst starting position, moving a codebase to your name is a solved, documented, one-afternoon problem. A developer who tells you it’s complicated is describing their incentives, not the technology.

§4The four documents

Documentation is where handovers usually rot, because “we’ll document it” has no pass condition. So each of my four documents ships with a test it has to survive. All four live in the repo’s /docs folder — they version with the code and transfer with it automatically.

• The README. Setup and deploy, from empty laptop to running system. The test: a developer who has never seen the project follows it top to bottom and the software runs. If they had to ask me anything, the README failed and gets fixed.
• The architecture note. What the pieces are and why they’re shaped that way, in plain words, with the stack named: React, Node.js, PostgreSQL — the same technologies half the industry works in daily. The named stack is the point. “Any developer can take over” is only true when the parts are ones any developer already knows.
• The operations runbook. Where the logs are. What the backups cover, how often they run, where they’re stored, and the exact steps to restore one. What runs on a schedule. What to look at first when something seems wrong. This is the document your next developer opens at 9 p.m. on a bad day, and it’s written for that moment.
• The decision log. The choices a future developer would otherwise re-litigate: why this database, why no framework there, why that queue was removed in week four. Ten minutes of reading that saves a week of “let me rebuild this properly first.”

An admission, because documents invite one: they age. A runbook nobody has touched in three years drifts away from the system it describes. That’s why each document carries a “last verified” date instead of pretending to be timeless. Any maintenance work I do ends with those dates refreshed. A dated document tells you exactly how much to trust it. An undated one asks you to guess.

§5The recorded walkthrough

The last milestone of every build is a screen-shared call, 60 to 90 minutes, recorded, and the recording is yours. It has a fixed agenda, and the order is deliberate:

• Deploy, live. I push a small change through the full deploy path while you watch. Not a rehearsed demo — the actual procedure from the README, proving the README.
• Restore a backup, live. I take last night’s backup and restore it in front of you. An untested backup is a hope, and hopes don’t survive disk failures. Five minutes of this call is worth more than any promise on this site.
• Walk the runbook. Logs, schedules, the what-to-check-first list, while the system is in front of us.
• Tour the code, top level only. Where things live and what talks to what — pitched at whoever watches this recording later, not at you personally.
• Your questions, for as long as they take.

The recording exists because the walkthrough’s real audience isn’t in the room. It’s the developer you hire in three years, who gets a 90-minute tour of the system from its builder. That works years after I’ve moved on, gracefully or under a bus. That’s the bus factor of one, answered the only way it honestly can be: on tape, next to the docs.

Two practical notes. The call is part of the fixed price — milestone five of five, never a billable extra. And bring whoever will own the system inside your business (§7 explains why that person must exist). The recording covers what they forget. Nothing replaces having watched the backup come back to life.

§6After the handover

Three things define the period after the call. First, the 60-day warranty: bugs I introduced, fixed free. What counts as a bug is not a debate, because the scope document from the scoping week defines what “working” means line by line. Inside the definition and broken: I fix it, no invoice. Outside it: a new quote you approve first, or decline.

Second, revocation. At the end of the walkthrough call, you remove my repo access and my server account — remember, they were always yours to remove. Then rotate the credentials I ever touched: database passwords, API keys. OWASP’s guidance is to rotate secrets regularly, so a stolen credential only works for a short time. A departing developer is the most sensible rotation trigger there is. This isn’t about distrust. Trust the person; rotate the key. Any developer who bristles at that has told you something useful.

Third, what ongoing help looks like. After the warranty you choose: a small care agreement with me, any developer you like, or nothing for now. I stay reachable either way and reply within 24 hours — but because of everything above, reaching me is optional. That’s the entire design. If you do want the care agreement, it’s small and specific. Dependency updates. The security patches your stack publishes. A periodic backup-restore check. The “last verified” dates from §4 kept current. A few fixed hours a month at a fixed price, cancelable any month. What it is not: a retainer that makes me the only person allowed to touch the system. The §7 conflict of interest applies to me too, and the structure is the answer to it. And the exit story stays boring forever. Your system’s data is a database on your own server, so leaving me costs a handover call. “Leaving” the software is a backup file, not a data hostage negotiation.

§7When a handover can’t save you

A good handover is necessary and insufficient, and pretending otherwise would undo the rest of this entry. Three failure cases survive every checklist:

• An exotic stack. If the build uses a niche framework or a language with a thin hiring pool, docs can’t save you. They can be perfect and you still won’t find the developer to read them. That’s why the stack choice in §4 is a handover decision made at kickoff. Boring technology is a feature you’re buying.
• No owner inside the business. Code transfers; operations don’t. If nobody on your team can say what the system is supposed to do on a normal Tuesday, no document fixes that. Before launch, one person in your business becomes the named owner — the one who watched the walkthrough and holds the vault. In a six-person shop that’s usually you or the operations lead. Assign them, or the handover lands on nobody.
• A vendor whose income depends on you staying. If a developer bills a monthly retainer to keep the lights on, their handover has a conflict of interest baked in, however sincere they are. Incentives beat documents. My projects are fixed-price precisely so my income ends when the build does. A clean handover is how I close a project, not a concession you extract from me.

And the widest case of all: if you rent your software, none of this applies, and that’s a genuine advantage of renting. The vendor runs the servers, keeps the backups, employs the developers — handover is their problem. It stays their problem right up until you want to leave, which is a different entry’s math. Renting outsources the handover. Owning makes it yours, once, on tape.

§8The one-line email that tests all of it

You now know what a real handover contains, which means you can test any developer before hiring them — me included. Send this: “Describe your handover. What do I hold on day one, and what do I receive at the end?”

A good answer names accounts, documents, and artifacts within a reply or two. My answer is this entry plus the milestone rail on the homepage, where handover is milestone five of five, in writing, on every quote. A vague answer (“everything’s always available on request”) is also an answer. It’s just one you should hear before the invoice exists rather than after.

Listen for three things in the reply. Named accounts: “the repo is created under your GitHub” beats “we use industry-standard version control.” Named documents with pass conditions, not “full documentation included.” And a warranty with a number in it. Anyone can promise a handover. The specifics are the difference between a process and a brochure.

If you want to see how a build gets defined tightly enough that “done” has edges, read how I scope a fixed-price build next. The scope document written there is the same one the warranty in §6 leans on. The two artifacts are one system: defined at the start, transferred at the end.