A Handover Checklist for Code, Repositories and Accounts

The end of a freelance engagement is when small gaps become expensive. The code works, the final milestone is accepted, and everyone moves on, until three months later nobody can deploy because the hosting account belongs to the developer's personal email, or the domain renewal reminders go to an inbox no one reads. A structured handover prevents this. The checklist below is written for the client side, but developers can send it to clients unprompted; it is a mark of professionalism.

Principle: the client owns, the developer is invited

The cleanest setup is decided at the start, not the end. Every account that the product depends on should be created under the client's organisation or email, with the developer added as a collaborator or member. Then the handover is mostly a matter of removing access rather than transferring ownership. If the project began the other way round, the steps below still work, they just involve more transfers.

The checklist

1. Source code and repository

• The repository lives under the client's GitHub, GitLab or Bitbucket account or organisation. If it was created under the developer's account, use the platform's repository transfer feature rather than re-uploading, so history, issues and pull requests come along.
• The default branch contains the deployed code. Verify by comparing the latest commit with what the hosting provider reports as the current deploy.
• A clean clone builds from scratch:

git clone <repo-url> handover-check && cd handover-check
cp .env.example .env    # fill with real values from the secrets list
npm ci && npm run build

• .env.example lists every required variable by name, without values.
• The README explains how to run locally, how to deploy, and where each service is configured.

2. Infrastructure and service accounts

Make an inventory table with one row per service: hosting, database, authentication, file storage, email sending, payments, analytics, error tracking, DNS and domain registrar, and any AI or third-party APIs. For each, record the owner account, the billing account, who currently has access and the plan. Ownership of the domain registrar account deserves special care, because losing it can take the whole product offline.

3. Secrets and credentials

• All production secrets are stored in the hosting provider's or backend's secret settings, owned by the client.
• Any secret the developer created or ever saw is rotated after handover. This is routine, not an accusation; it is how you know exactly who holds which credential.
• Personal access tokens, deploy keys and SSH keys belonging to the developer are removed from repositories and CI settings.

4. Data and backups

• Database backups are enabled and the client knows where to find them.
• One restore has been tested, even if only to a separate project.
• Any data exports, seed scripts and migrations are in the repository.

5. Access removal

Once the above is verified, remove the developer's access in each service from the inventory, unless an ongoing support arrangement has been agreed. Keep a dated note of what was removed.

Documentation worth asking for

Beyond the README, three short documents save the next developer days:

1. An architecture note: a page describing the main components and how data flows between them.
2. A known issues list: what was left undone, deliberately postponed or discovered late.
3. A runbook: how to deploy, roll back, rotate a key and restore a backup, written as commands rather than prose where possible.

If the app was built partly with an AI tool such as Lovable, Bolt or Cursor, also ask the developer to note which parts were generated and which were hand-written or heavily modified. It helps whoever next decides whether to regenerate or edit a file.

Closing the engagement on the record

A handover is also the moment to make the engagement itself verifiable. For freelancers, a completed contract that a client can confirm is worth more than a line on a CV. On Workli, for instance, contracts recorded on the platform feed the freelancer's Work Passport, a verified work history with jobs completed and on-time delivery from dated milestones, and clients can confirm the engagement from their own account. If you are curious how that record works, you can learn more on the site; whichever platform you use, closing the loop with a confirmed record helps the next client trust the work.

Handover is unglamorous, and it is usually done in a rush at the end of a project. Spend two hours on this checklist instead, and the client gets a product they can genuinely run without the original developer, while the developer leaves a clean, professional final impression. Both outcomes are worth far more than the time it takes.