How to verify a Rails handoff in one afternoon

You paid for a Rails app. The developer says it is done. Whether it is yours — whether you can run it, deploy it, and hand it to someone else without them — is a separate question, and it takes about three hours to answer. Here are the nine checks. Seven need no technical skill at all; two need a terminal or a developer for an hour.

1. Are you the owner on GitHub?

Open the repository on GitHub. Look at the URL: it should be under your organization or account, not the developer's. Then Settings → Collaborators. You should see the developer listed as a collaborator you could remove. If the repository lives under their account and you are the guest, ask for a transfer today; it is a two-minute operation on their side.

2. Is the hosting billed to you?

Log in to wherever the app runs (Heroku, Render, Fly, Hatchbox, a VPS). The account should be yours and the invoice should carry your name. Same for the database, the email provider, and the domain. Anything billed to the developer is something that stops when they do.

3. Is there a runbook, and can a stranger follow it?

Look in the root of the repository for RUNBOOK.md (or README.md with a Deploy section). It should answer, in order: how to run it locally, how to deploy, how to roll back, where the secrets live, how to back up and restore. Then the real test: ask someone who has never seen the app to deploy from it while you watch. If they get stuck, the runbook is not finished.

4. Do the tests exist, and do they pass?

This is one of the two technical checks. On a machine with the app set up:

bin/setup
bin/rails test

You are looking for a suite that runs and passes, and for tests on the things that would cost you money: sign-up, sign-in, payment, and the core action of the product. Open the test/ folder and read the file names; you do not need to read the code to see whether test/system/checkout_test.rb exists.

5. Is there a recorded walkthrough?

Somewhere in the README there should be a link to a 20–30 minute screen recording: where things live, why they are there, what to touch first. It is not for you. It is for the developer you hire in a year, and it turns a week of archaeology into an afternoon.

6. Is it standard Rails with public gems?

Open Gemfile. Every line should reference a gem from rubygems.org. What you do not want to see:

# a private registry or a repo you cannot open
source "https://gems.example-agency.internal"
gem "agency_core", git: "git@github.com:example-agency/agency_core.git"

A private gem or an in-house framework means the next developer must learn something nobody else knows, and that only the original developer can update. Ask for it to be replaced with the standard Rails equivalent, or vendored into your repo.

7. Are secrets out of the code?

Grep the repository for anything that looks like a live key. From the repo root:

git grep -nE "(sk_live|sk_test|AKIA|BEGIN (RSA|OPENSSH) PRIVATE|SG\.|xox[bp]-)" -- . ':!*.enc'

It should print nothing. Secrets belong in Rails encrypted credentials (config/credentials/*.yml.enc), with the master key in your password manager, not the developer's. If the grep finds anything, rotate that key today; the runbook should say how.

8. Has the backup ever been restored?

The other technical check, and the one most often skipped. The runbook should name where backups go, how often, and the restore command. Then ask for the date it was last restored — not taken, restored — and have it done once more while you watch:

# example shape; the runbook has the real command for your host
pg_restore --clean --no-owner -d "$DATABASE_URL" latest.dump

A backup that has never been restored is a hope. Write the date next to "last restored" in the runbook.

9. Does anything stop working if you cancel the retainer?

Ask the developer directly: if we stop paying you tomorrow, what breaks? The correct answer is "nothing; you would need someone to apply updates eventually." Any other answer names the thing you do not yet own.

What to do with the results

If all nine pass, you own an app. If the runbook or the backup restore fail, do not pay the final invoice until they exist; those two are the whole point. If several fail and the developer has already gone, that is what the diagnostic is for: one day, everything read, and a written answer about what it would take to make the app yours.