Agency delivery
How to check a website handover before the developer moves on
The website works, the files have arrived and the project is ready to close. Then another developer asks how to build it, where the email service is configured or who owns the hosting account. A good handover answers those questions before they delay the next change. Review what the receiving team can actually do using the access and instructions provided.
Start with account ownership and working access
List the source repository, domain, hosting, deployment service, business email, payment connection and other external tools. Record the intended owner, operational contact and the approved way to obtain access. A contractor may need access to an account without becoming its long-term owner.
Have the receiving person verify that invitations work and permissions are appropriate. With GitHub, repository transfers can retain existing collaborators and associated integrations. Review them after the transfer. Keep the record factual: name who controls an account and which access remains to be arranged.
Give the setup guide to someone new
Ask for the runtime versions, installation steps, build command and required configuration names. Secret values should have an approved secure access path. The guide needs to explain where authorised people obtain them without placing credentials in public documentation.
Use a clean test environment and ask someone who did not build the project to follow the instructions. Have them reach a working staging page. Note every question they need to ask and add the answer to the guide. This is a simple way to uncover steps that exist only in the original developer's memory.
Describe the services behind the website
List the external tools and scheduled processes on which the website depends. For each one, explain its purpose, account owner, renewal responsibility and failure notification. Include the part of the customer journey affected if the connection stops working.
Keep open issues in one accessible place with reproduction steps and agreed priorities. Distinguish an existing defect from a requested new feature. For example, a confirmation email going to the wrong address needs a different conversation from adding a new reporting dashboard. Record who is responsible for each item.
Finish with a small release rehearsal
Choose a harmless change in staging, such as updating a test page. Ask the receiving team to build it, deploy it and verify the result using the instructions. Practise returning to the previous version in that environment and document any step that was missing.
Agree who approves future releases, who handles urgent problems and what ongoing maintenance includes. Set a practical route for transition questions and keep the current instructions in a place the responsible team can access. The final review should show that another person can continue the work, not simply that files were delivered.
Your next step
A practical checklist
- Intended owners can access the required accounts.
- Source history and open issues are available.
- A second person can follow the setup guide.
- Secret values have an approved access path.
- External services and renewal owners are recorded.
- A small staging release and rollback have been rehearsed.
- Support responsibilities and outstanding work are agreed.