How to take over a project from a freelancer (a handover checklist)

Key points

• Get owner-level access to every account first, in your company’s name.
• Ask for setup steps, a list of environment variables and deploy steps, not just the code.
• Prove that someone else can build and deploy the project while the freelancer is still reachable.
• Remove old access and change passwords and keys after the handover, even when you part on good terms.
• Expect a new team to start with a review, not with new features.

Why handovers go wrong

Most handover problems are not about the code. They come from accounts: a domain registered with the freelancer’s personal email, a cloud account on their card, an app published from their own developer account. When the work ends, the company finds it does not control the product it paid for.

The other common problem is knowledge that lives in one person’s head: how to run the project locally, which settings production needs, and the manual step before every deploy. Code without that knowledge can take a new developer a long time to get running.

The steps are the same whether the freelancer is moving on, has gone quiet, or you simply want a new team. What changes is the order. If they have gone quiet, start with what you can reach yourself today: accounts already in your company’s name, the domain registrar and the payment provider dashboard.

What to secure first

Ask for owner rights, not just a login. An admin invited into the freelancer’s account can be removed by them; an account the company owns, with the freelancer invited as a collaborator, cannot be taken away.

Apps can usually be moved without taking them off the store. Apple lets the Account Holder transfer an app to another developer account, and the app keeps its reviews and ratings while users keep getting updates. Google Play has its own transfer request, which needs both developer accounts to be registered and active, and linked services such as Firebase have to be linked to the new account again.

Plan the domain move with the registrar before changing anything. Under ICANN’s rules, changing the registrant’s name, organization or email can lock the domain against moving to a different registrar for a period, so decide first whether it is staying where it is.

What documentation and knowledge to ask for

• Setup instructions: how to install and run the project on a new machine, written so that someone who has never seen it can follow them.
• A list of environment variables: every name, what it is for and where its value comes from. The values themselves go into the password manager, never into chat or email.
• Architecture notes: the main parts of the system, the outside services it depends on, and where data is stored.
• Deploy steps: how a change gets from the repository to production, including any manual step.
• Open issues: known bugs, unfinished work, shortcuts taken on purpose and anything the freelancer was worried about.
• Scheduled jobs, backups, and where logs and errors are reported.
• Anything that exists only on the freelancer’s machine, such as the signing keys for a mobile app.

Settings that change between environments belong in environment variables, outside the code. The Twelve-Factor App gives a simple test: the code should be safe to make public at any moment without exposing a single credential. If it is not, there are secrets in the repository, and they need to be moved out and replaced.

The shortcuts a freelancer mentions are technical debt. What is technical debt? explains how to judge which ones matter.

Prove you can build and deploy without them

1. Have a developer who is not the freelancer clone the repository from your company’s account and follow the setup instructions on a clean machine.
2. Fill in the environment variables from the password manager, not from old messages.
3. Run the tests, if there are any, and note which parts have none.
4. Deploy a small, harmless change to a staging environment and then to production, using only accounts the company owns.
5. Restore a backup into a test environment, so you know the data can be recovered.
6. Write down every point where you had to ask the freelancer for help, and add the answer to the documentation.

Do this while the freelancer can still answer questions. Each answer you get now is one the next team does not have to work out from the code. If there is no staging environment or no automated deploy, What is CI/CD? explains what to set up.

What a new team checks in its first review

• Ownership: that every account in the table above is really in the company’s name.
• Security: secrets in the code or its history, outdated dependencies, exposed admin pages and missing access checks.
• Code health: how the code is organized, whether it has tests, and the parts nobody wants to touch.
• Data: where it is stored, whether backups run, and whether a restore has ever been tested.
• Deploys: whether a release can be repeated by anyone or depends on one person’s machine.
• Open issues: what is broken today and what users are complaining about.

A good team tells you what it found and what it would fix first before it proposes new features. The web app security checklist covers the security side in more detail. If the review suggests starting over, read Rewrite or refactor? before agreeing: most code can be improved in place. Code written with AI tools has its own common gaps, covered in Vibe coding to production.

How to part on good terms

• Tell the freelancer early and plainly, and ask for their help with the handover as a defined piece of work.
• Agree on what they will hand over, using the checklist below, so both sides know when it is done.
• Settle what you owe for finished work promptly. Someone waiting on money has less reason to help.
• Agree that they stay available for questions for a short, set period after the handover.
• Thank them, and offer a reference if the work was good.

Then remove their access and change the passwords and keys they knew, even if you trust them. It is routine, not an accusation. On GitHub, removing a collaborator deletes their forks of a private repository but not the copies already on their machine, and GitHub notes that the owner is responsible for making sure people who lose access delete confidential information. If your contract covers confidentiality, ask them to confirm they have deleted their copies.

The handover checklist

• Repository in the company’s account, with its full history, and you as an owner.
• Hosting and cloud accounts owned by the company, with billing in its name.
• Domain registered to the company, registrar login in your hands, DNS records saved.
• Apple and Google Play apps in the company’s own developer accounts.
• Owner or admin access to every third-party service, the company email, analytics and the payment provider dashboard.
• Every secret in a company-owned password manager.
• Setup instructions, environment variable list, architecture notes, deploy steps and open issues written down.
• A deploy to production done by someone other than the freelancer.
• A backup restored and checked.
• Freelancer access removed, and every shared password and key changed.

When BYD Tech starts a project, the code lives in the client’s GitHub from the first day, and cloud and app store accounts are opened in the client’s name, so there is less to hand over at the end. Web app development describes how we work.