Agency delivery
A development handover checklist for US agencies working remotely
A US agency receiving work from a remote developer needs more than the final design and a download of the source. The receiving team should be able to run the project, understand its dependencies and make an agreed change without relying on the original developer's memory. Treat that capability as a deliverable with a short, observable acceptance exercise.
Create an ownership and access register
List the repository, domain, hosting, deployment service, business email, payment connection and other external tools. Record the intended account owner, operational contact and where authorised access is managed. Separate the client's ownership from the access a contractor needs to carry out work.
Verify access with the receiving person rather than assuming an invitation was accepted. With GitHub, repository transfers can retain existing collaborators and associated integrations. Review the actual permissions and connections after a transfer. Account ownership and a finished website are separate checks.
Make the project reproducible
Ask for a setup guide that names the runtime versions, installation steps, build command and required configuration names. Keep secret values in an approved secure access system. The guide should explain where authorised team members obtain them without placing credentials in public documentation.
Give a team member who did not build the project the guide and a clean test environment. Have them reach a working staging page. Every undocumented question they must ask is a useful addition to the handover notes. Record known limitations instead of presenting a partial setup as complete.
Document dependencies and unfinished work
A website may depend on a form service, payment provider, scheduled task, licensed plugin or an external API. For each dependency, identify what it does, who manages renewal or billing and who receives failure alerts. Confirm which features are included in the delivered scope.
Keep open issues in one accessible place with reproduction steps and their agreed priority. Distinguish a known defect from a future enhancement. For example, an incorrect confirmation email is different from a request for a new dashboard; the handover should not blur those responsibilities.
Rehearse a small release and recovery
Choose a harmless staging change, such as updating a test page. Have the receiving team build it, deploy it and verify the result using the documented process. Practise returning to the earlier version in that test environment.
End with the decisions the agency needs after handover: who approves releases, who handles urgent problems, what maintenance includes and where the current instructions live. Specify a practical route for questions raised during the transition. The exercise should produce a usable record of access and actions, not merely a meeting recording that nobody has checked.
Your next step
A practical checklist
- Intended owners can access the required accounts.
- Repository history and open issues are available.
- A second person can follow the setup guide.
- Secrets have an appropriate access path.
- Integrations, licences and alert owners are listed.
- A small staging release and rollback have been rehearsed.
- Support responsibilities and outstanding items are agreed.