The handover package: 10 things a client should hold when your project ends

"It works on the demo server" is not the same as "the client can keep running it without you."

Most handover pain we've seen doesn't come from bad code. It comes from things that were never written down or never moved out of the developer's accounts. Here is the 10-item package we put together before the last invoice, with one line on why each matters and one way to verify it.

The 10 items

1. Repository in the client's account
Why: if the code lives only in your personal GitHub, the product becomes unfixable the day you're unreachable.
Check: the client clones from their org and sees the full commit history, not a squashed zip.

2. Domain, cloud, app store and payment accounts in the client's name
Why: only the account owner can renew, cancel or transfer. Store publisher and merchant accounts are often hard or impossible to move later.
Check: the client logs in to each console themselves and sees their own name, email and payout account.

3. Admin credentials, handed over safely
Why: without admin access they can't change their own product.
Check: share through a password manager, not chat or email. The client rotates everything immediately and disables your account.

4. A complete .env.example
Why: without the DB address and third-party keys nobody can rebuild the environment.
Check: every variable name is listed with a one-line description; the real values are sent separately and bring up a fresh environment.

5. A run-and-deploy guide that works without you
Why: if the next developer's first question is "how do I deploy this?", that's paid hours.
Check: give the doc alone to another developer on a blank machine. Can they get it running without messaging you?

6. Backup and a tested restore
Why: a backup that has never been restored is a hope, not a backup.
Check: say where and how often backups go, then restore the latest one into a test environment together.

7. Paid services and monthly cost table
Why: email sending, maps, AI calls and servers tend to surface for the first time on a bill after handover.
Check: one table with service, purpose, billing cycle and expected monthly cost, and the total roughly matches what you quoted.

8. Licence list (open source, images, fonts)
Why: an asset that doesn't allow commercial use can mean takedowns later.
Check: name, source and licence type per item, plus receipts for anything purchased.

9. Warranty window and how to report bugs
Why: the first bug after launch is stressful if nobody knows where to send it.
Check: start/end dates of the free-fix period, a reporting channel and a target reply time, in writing.

10. A handover memo for the next developer
Why: code doesn't explain why it's built this way or which parts are fragile.
Check: at least one page on structure, known issues, postponed work and "don't touch without reading this" areas.

Order matters

Go through the list before the final payment. After that, everyone has less leverage to chase missing pieces. If something can't be delivered on the day, write down (email is fine) what is missing and when it will arrive.

This is general practice, not legal advice. Contract wording around source code and IP is worth a professional review.

The full checklist, with links to the related guides on contract clauses and acceptance testing, is here: Handover checklist: 10 things to receive when an outsourced project ends

We're a small dev studio in Korea (HS Solution) and we write these checklists from the client side, so we're curious what's on your handover list. What's the one item you've had to chase after a project was "done"?