# A freelance project handoff checklist for finished work

A project handoff should tell the client what was delivered, where it lives, how to use it, and which items remain open. Keep delivery separate from approval and payment status. A file sent successfully does not establish that the client has accepted it or that every part of the agreement is complete.

## Inventory the actual deliverables
Start with the agreed scope and list the files or access being transferred. Identify current versions and remove ambiguous names such as “final-final-new.” Keep working files separate from the versions intended for use.

For a fictional invitation project, the handoff might include a print PDF, a web image, and an editable source file if that source file is part of the agreement. Do not promise source files, licenses, or ownership terms beyond what you are authorized to provide.

## A practical handoff sheet
| Item | What to record |
| --- | --- |
| Deliverable | Name, version, format and intended use |
| Location | Link or folder with the client's access confirmed |
| Setup or use | Instructions needed for the next person |
| Included materials | Sources, licenses or dependencies relevant to use |
| Open items | Specific issue, owner and next step |
| Approval | Actual status and record, separate from delivery |
| Support | What is agreed, for how long, and how to request it |

If a row is not applicable, say so. A small one-file project does not need a technical manual. A website handoff may need access and operational information that an invitation does not.

## A fictional final-delivery message
```text
Hi Riley,
The invitation files are in [folder]. The folder contains:
- invitation-print-v3.pdf for the printer
- invitation-web-v3.jpg for the email invitation
The event details match the version approved on [confirmed date].
The printer's proof is still to be reviewed; it is not part of the
approval described above.
Please let me know if you cannot open the folder.
Agreed next step: [actual action and owner]
```

The message distinguishes a delivered file from a later proof. It does not claim the event details were approved unless you have that record. Name any missing deliverable explicitly rather than presenting a partial handoff as complete.

## Transfer access through the proper channel
Confirm the client can reach the files using their own account or the agreed sharing method. Do not send passwords or other secrets in a generic project summary. Use the appropriate account-transfer or secure credential process when access is part of the work.

If you have temporary access to the client's systems, agree on when it ends and remove it through the normal process. Record who owns ongoing operations. Sending instructions without confirming that someone has the required account can leave a project unusable.

## Ask AI to check the handoff against scope
```text
Compare this draft handoff with the agreed deliverables.
Identify missing files, unclear versions, access assumptions, and open items.
Separate delivered, approved, and still-to-do statuses.
Preserve the actual support and ownership terms; do not expand them.
Suggest a concise client message and a checklist for me to verify.
Scope and draft handoff: [redacted text]
```

## Finish with a usable record
Open the delivered files, check the links, and inspect names and versions before sending. Keep the delivery message and the client's response with the project record. If something is unresolved, identify the next action and the person who can take it.

A good handoff helps the next person use the work without reconstructing your whole project history. It should be proportionate to the project and truthful about what has been transferred.

---
SkillStall · 2026-10-03