Resource for agencies worldwide
Agency development handover checklist
Use this checklist when handing a website, mobile app or custom application brief to a development partner. It helps expose missing decisions before they affect an estimate or delivery.
Before sharing files
Start with context, not a folder of assets.
A useful handover explains the client goal, the people making decisions and what must be true at launch. Designs and technical details make more sense after that context is clear.
Incomplete items do not have to stop the first discussion. Mark what is unknown, who will decide it and when the project needs that answer.
The checklist
Six parts of a dependable development brief
1. Client, team and decisions
- Name the agency lead, client decision-maker and technical contact.
- Explain who communicates with the client and whether development is white-labelled.
- Record the review process, expected response times and final approval owner.
- List the working tools for messages, files, tasks and meetings.
2. Outcome, users and scope
- Describe the business outcome and the action each main user needs to complete.
- Separate required launch scope from later ideas and optional improvements.
- List user types, important journeys and accessibility or language needs.
- Add acceptance criteria that can be reviewed, rather than relying on broad terms such as fast or intuitive.
3. Designs and content
- Share the approved design file, prototype and component or brand guidance.
- Mark which screens are approved, under review or still missing.
- Provide final copy and assets, or identify the person responsible and delivery date.
- Include responsive behaviour, empty states, errors, emails and other states that may not appear in the main design.
4. Technology and integrations
- Describe the existing website, application, repository and hosting arrangement.
- List integrations, API documentation, data sources and the owner of each external system.
- Record supported browsers, devices, app-store requirements and any agreed technology constraints.
- Identify migration, redirect, analytics, SEO and performance requirements before estimating the work.
5. Access and environments
- List the accounts and environments needed for development, review and release.
- Invite named people through each provider. Do not place passwords, recovery codes or private keys in the brief.
- Confirm who owns domains, hosting, repositories, analytics, email delivery and app-store accounts.
- Plan how access will be reviewed or removed at the end of the engagement.
6. Quality, privacy and launch
- Define the review devices, test data and people responsible for acceptance testing.
- Identify personal data, consent needs, retention rules and security requirements for the project.
- Agree the release owner, rollback approach, monitoring and the checks needed after launch.
- Document the final code, access, deployment process, known issues and support arrangement during handover.
Have a brief, even if it is incomplete?
Share what you have and identify the missing decisions. We can discuss the technical questions, delivery responsibilities and next step with you.