The Handoff Standard
You own the engine.
Here is how you check.
The fastest way to get burned twice is to escape one black box into another. So every run ends with the same list, and every item on it comes with a way to verify it yourself, before the second half of the fare is due. If you hand this to a different developer next month, that is what it was built for.
The standard
Nine items. Every run. No exceptions.
This is the answer to the bus-factor question. Not a promise that I will be around, but a set of deliverables that make it not matter.
- The repository lives in your GitHub organization from day oneVerify: Open GitHub. You are the owner. We are a collaborator you can remove.
- Deployed to infrastructure billed to your accounts, not oursVerify: The hosting invoice has your name on it. Log in and see the app running.
- A written deploy and rollback runbook, not tribal knowledgeVerify: RUNBOOK.md in the repo root. Follow it. It should take one sitting to deploy from a clean machine.
- Tests on the paths that would cost you money if they brokeVerify: Run the suite. Sign-up, sign-in, payment, and the core action each have a test with your data shapes.
- A recorded walkthrough for the next developer, not just for youVerify: A 20–30 minute screen recording linked from the README: where things live, why they are there, what to touch first.
- Standard Rails, no proprietary wrappers or in-house frameworksVerify: Gemfile is public gems only. Nothing points at a private registry or a repo you cannot see.
- Secrets in encrypted credentials, never in the code or the front endVerify: Grep the repo for a key. Find none. The master key is in your password manager, not ours.
- A database backup that has been restored at least onceVerify: The runbook names the backup location and the restore command, and there is a date next to 'last restored'.
- No retainer required to keep any of it runningVerify: Cancel the Roundhouse. Nothing changes. That is the point.
What is in the runbook
Tribal knowledge, written down.
RUNBOOK.md lives in the root of the repository. It is written for a competent developer who has never seen the app and has one afternoon.
Run it locally
One command to bring up the containerized environment. What the seed data is. Which reserved-domain emails are safe to use.
Deploy it
Where it is hosted, under which account, the exact commands, and how long it takes. What the health check is and where to look when it fails.
Roll it back
The command, and how to tell it worked. Written before it is needed, because that is when it is impossible to write.
Secrets and access
Where the master key lives (your password manager). Which third-party accounts exist, who owns them, and what breaks if each one lapses.
Back up and restore
Where backups go, how often, the restore command, and the date it was last actually restored.
What to touch first
The three files that matter, the decisions that were made on purpose and why, and the Later list of things that were deliberately not built.
Score what you have
Try it on your current app.
The list works as a scorecard for anything, not just apps that came out of a run. Go down it against what you have today. Every item you cannot verify is a place where you depend on a person or a tool you may not have next year.
Three or fewer verifiable? That is normal for something built fast, and it is the shape most rescues start in. It is also exactly what the diagnostic is for.
Inspect it on day five.
Twenty minutes on a call, free. If you have been burned by a handoff before, bring the story. It usually turns into an item on this list.
Book the 20-minute callbill@atomiclocomotive.com · Austin, Texas · Usually replies same day