Project Handover Checklist Generator

Most handover problems are not technical. They come from things nobody wrote down: which email owns the domain, which keys the old developer still holds, what "finished" was supposed to mean. This generator turns a short form into a structured handover document that covers those gaps. Everything runs in your browser, and you can export the result as Markdown or print it to PDF.

What the generated document includes

• Project summary: what the product does, who uses it, the stack and where it runs.
• Accounts to transfer: domain registrar, DNS, hosting, database, code repository, email sending, payments, analytics, app store and any AI or third-party APIs, each with its current owner and the target owner.
• Access by invitation: for every service, how the new developer gets in through a collaborator, team or member invite, at the lowest role that lets them work.
• Environments: local, staging and production, with their URLs, how to deploy to each, and which data each one uses.
• Credentials to rotate: every key, token and password the previous developer could reach, with a tick box for when it was replaced.
• Known issues: bugs, missing features, workarounds and anything that "only works if you do it this way".
• Acceptance criteria: concrete checks that decide when a piece of work is done.
• As-found condition: a dated snapshot of what works and what does not on the day the project changes hands.

How to fill it in well

Be specific about owners. "The client" is not an owner. Write the account email or the person's name and role. If you do not know who owns an account, that is a finding in itself; put it at the top of the known issues.

List names, never values. The document should say "Stripe secret key, stored in the host's environment variables, owned by the business account". It should never contain the key itself. Our guide on giving a developer access without sharing passwords shows how to invite people to the common services instead.

Write acceptance criteria someone could test. "Checkout works" is vague. "A new user can buy the monthly plan with a test card, receives a confirmation email, and sees the plan on their account page" can be checked by anyone. Good criteria prevent most disputes about whether work is finished.

Describe the as-found condition honestly. Note what you tested, how, and when. If the app has not been deployed in months, say so. This protects the owner and the incoming developer equally.

After you export

1. Share the document with the incoming developer before work starts and agree on it together.
2. Send the invites listed under "Access by invitation" and confirm each one was accepted.
3. Once the new developer has access, rotate the credentials in the list and remove the previous developer's access.
4. Attach the document to your written agreement. See paying a developer safely for how milestones and acceptance criteria fit together.

Before sharing any code, the Secret Leak Scanner can show whether keys are sitting in config files, and the Repo Health Check gives the incoming developer a quick picture of a public repo.

When the previous developer is gone

You can still use the generator if the person who built the project is unreachable. Fill in what you know, mark the rest as unknown, and treat every unknown account as a priority. Our guide on securing your code, domain, hosting and accounts explains how to regain control step by step, and the complete handover checklist guide covers the full process in more depth.

Limitations

The generator builds a document from your answers; it cannot check that an account exists, that an invite worked, or that a key was really rotated. It is not legal advice and not a contract. Review the output before you rely on it, and adjust sections that do not fit your project.

Ready to hand the project on?

If you are handing over because an agency or freelancer stepped away (see agency abandoned project), a clear document makes your listing far easier to answer. Post your takeover for free and mention that a handover document is ready; developers can then judge the work before the first call.