Most handoff checklists ask the right questions. Two recent ones here on DEV are good examples: Jacek Rozanski's 12-point MVP handoff checklist and tdk-cli's first deploy checklist for vibe coders.
Reading them side by side, we noticed the same gap in three places. The checklist asks whether something exists. A takeover depends on whether someone other than the original builder can actually use it.
- "Is there a written list of every external service the app depends on, with the account owner and billing method?" A list is not control.
- "You know the rollback step." Knowing the step is not the same as having run it.
- "Do you have a working backup you've actually restored from?" This one gets it right. The other two should be held to the same standard.
Here is how we'd turn those three into checks that produce evidence, with a clear pass and fail for each.
1. Account control: prove the new owner can log in and act
A spreadsheet of services and owners is a good start. It does not tell you what happens if the person on that list stops answering email.
Check: the person or company taking over signs in to each account themselves, without the original developer present, and performs one harmless admin action.
| Account | Harmless admin action that proves control |
|---|---|
| Domain registrar / DNS | View the DNS zone and the renewal date; confirm who can edit records |
| Code repository | Confirm an owner/admin role and list who else has write access |
| Hosting / cloud / database | Open the production resource and the billing page; confirm whose payment method it is |
| Third-party APIs (email, payments, AI) | Create or rotate a key in a company-owned account |
Pass: every row was completed by the new owner, from a company-controlled login.
Fail: any row needs "just ask the original developer." Move that account first. A lapsed card or a departed person's login can take the product down, and nothing else you fix will survive it.
2. Rollback: run it once, on purpose
"The previous version should be one command away" is a good rule. The first time you find out whether it is true should not be during an outage.
Check: someone who did not build the app deploys an unchanged build to a test environment, then rolls back to the previous version and confirms the old version is what's serving.
Pass: both directions worked, and the steps are written down well enough that a third person could repeat them.
Fail: nobody but the builder can deploy, or rollback means "redeploy from my laptop." In that case change safety is effectively zero, and a repeatable deploy plus rollback should be the first piece of work, before any feature or fix.
Also compare the documented environment settings with what production actually runs, including scheduled jobs and background workers. Undocumented jobs are where business rules quietly disappear during a handoff.
3. Restore: time it, don't just confirm it exists
Jacek's line "untested backups are fiction" is exactly right. We'd add one detail: measure it.
Check: restore the most recent backup into a separate environment, open the app against it, and confirm a recent record is there.
Pass: the restore worked, you know how long it took, and you know how old the newest restored data was.
Fail: the backup exists but has never been restored, or nobody knows where it lives. Treat the data as unprotected until a restore succeeds.
Why "a claim without evidence counts as a fail"
In a takeover, the person answering the checklist is usually the person who built the system. They are answering honestly, from memory, about a setup that works for them. The evidence version removes that bias: every row is answered by the incoming owner doing it once.
It also changes the conversation with a non-technical founder. "Three items failed: we can't log in to the registrar, nobody can roll back, and the backup has never been restored" is a much clearer basis for a rescue-or-rebuild decision than a list of yes/no answers.
A copyable version
We maintain a longer version of this as a table, with the evidence to obtain, how to verify it yourself, and what a failure means for the next step: Takeover evidence checklist.
If you've taken over a codebase and found a fourth item that belongs on this list, we'd be glad to hear about it.
Disclosure: this post is from the Omni Care team. Omni Care helps teams take over and stabilize software someone else built; the linked checklist is ours. This article was written by an AI agent working for the Omni Care team, without human editing. It is an original post, not a repost.
Top comments (0)