A useful freelance handover tells the client what has been delivered, which version to use, how to access it and what happens if they need help afterward. Sending a folder is one part of that process. The handover is complete operationally when the intended person can find and use the agreed output.
Build the delivery around the client’s next task. A marketing manager may need the approved export for a campaign. A future designer may need editable files and dependencies. A site administrator may need access and operating notes. These are different needs, even when they relate to the same project.
Use the agreed scope, delivery terms and any organization-specific requirements to determine what is included. The checklist below is a working method for organizing delivery, not a replacement for those agreements.
Confirm the exact delivery list
Start with the agreed deliverables and compare them with the files or systems you are about to hand over. Mark each item as included, already delivered, awaiting a decision or outside the agreed delivery. Resolve discrepancies rather than burying them in a large folder.
The broad purpose is consistent with Atlassian’s project-closure guidance: bring the work to a clear close, confirm outcomes and document what remains. A solo project can use a much smaller record than a large organization while retaining that clarity.
Avoid calling the package “everything” when it contains only selected exports. Equally, do not assume that every internal draft, experiment or tool you used belongs in the delivery. Check what was agreed and describe the actual contents accurately.
Our guide to setting freelance project scope can help make these distinctions earlier in the work. At handover, your immediate job is to reconcile the list you already have.
Identify the recipient and their next action
Ask who will receive, use and maintain the output. These may be different people. A client contact can approve a project without being the person who opens an editable file or manages an account afterward.
Write a short use case for the delivery: “The campaign coordinator needs to upload the approved social images,” or “The incoming developer needs to run the project locally.” That sentence helps you decide which instructions belong at the top of the handover.
Then check what the recipient needs to accomplish that action. Do they need a particular application, access role, format or separate asset? If the answer is uncertain, confirm it before presenting the package as ready for use.
A common avoidable mismatch is delivering a technically correct file in a form the recipient cannot use. The fix may be an agreed export or a short explanation, not a new project. Discovering the mismatch before delivery gives both parties room to decide.
Create a small delivery index
Put a readable index at the top of the package or in the delivery message. A client should not have to open twenty files to discover which is final.
| Item | What the index should explain |
|---|---|
| Final outputs | Which files are intended for immediate use |
| Editable source | What is included and what application it needs |
| Dependencies | Required assets, services or separate access |
| Operating notes | The small set of tasks the client is expected to perform |
| Open items | Any unresolved decision and its named owner |
| Support route | Where to report a problem or request further work |
A fictional design package might contain a delivery note, an “Approved exports” folder and an “Editable source” folder. The index could say that the exports are ready for the agreed campaign, while the editable document requires the specified design application and licensed fonts.
The structure should match the job. A copywriting project might need one approved document, a change summary and a short note about publication fields. It does not need a complex archive just because a larger project once used one.
Remove version ambiguity
Use filenames and folder names that distinguish working drafts from approved delivery. If you include historical versions for an agreed reason, keep them separate and identify them as historical. Do not leave the client to choose between “final,” “final2” and “final-revised-really.”
A date and a clear version label can help. For example, “Campaign-copy_2026-10-08_approved” identifies a particular artifact more clearly than “latest.” Use whatever convention the client’s workflow requires, and state the version in the delivery note.
If a small correction is made after handover, explain which file replaces which. A replacement should not silently coexist with the obsolete version in a folder where both appear equally valid.
For work that uses a repository, identify the agreed release or commit rather than pointing only to a branch that will continue to change. For a shared document, clarify whether the link is a live working document or the delivered snapshot.
Test access as a recipient would use it
Open the delivered exports and check that they are the intended files. Then verify access with the actual recipient or through your approved testing process. Your ability to open your own link does not prove the client has the required permissions.
Google Drive’s sharing guidance distinguishes viewer, commenter and editor access. A person who can read a document may still lack the permission needed for the task you are handing over. Check the relevant action, not just the link.
Do not solve an access problem by publishing confidential material to anyone with a link unless that is appropriate and authorized. Use the intended account and the agreed sharing method. Transfer account responsibility through the platform’s supported process where required; avoid handing over your personal login.
If a link has an expiry or relies on a service you intend to stop paying for, make that dependency visible and agree on a durable delivery arrangement. A working link today is not automatically a long-term archive.
Describe dependencies without assuming they transfer
Editable files can depend on fonts, images, plugins, templates or paid services. List what the client needs and distinguish included materials from things they must obtain or maintain separately.
For example, Adobe’s font-packaging guidance explains that packaging a document does not automatically permit transferring font files. The applicable license determines what can be shared, and recipients may need their own access. Check the actual asset terms rather than treating a software packaging feature as permission.
Keep the handover note practical: name the dependency, explain what it affects and point to the relevant official information. You do not need to reproduce the license or offer a legal interpretation of every possible use.
For a website, the comparable list might include hosting, a domain, a paid extension and a renewal contact. For a report, it might include linked data that will not refresh without access. The useful question is what will stop working or become difficult to edit if the dependency is missing.
Write instructions for the expected maintenance task
Document what the client is actually expected to do next. A short tested procedure is more useful than a broad manual full of features outside the project.
For example, a content handover might explain how to locate the approved text, where to place its title and description, and which links need checking after publication. A design handover might explain which export is intended for print and which for a digital channel, based on the agreed specifications.
Use a walkthrough only where it resolves a real uncertainty. If you record one, avoid showing unrelated client information or credentials, and provide a written pointer to the important steps. A video should not be the only place the delivery location or support boundary is documented.
Ask the recipient to try the most important operation. If they cannot complete it, update the instructions or identify the missing access before closing the operational handover.
Separate receipt, review and additional work
“I received the files” and “I approve the deliverables” are different statements. Request the confirmation appropriate to your agreed process and keep the record with the project. Do not treat silence as approval unless the applicable agreement actually establishes that mechanism.
If a problem is reported, identify whether it concerns delivery, an agreed correction or a new request. Our guide to handling revision rounds can help keep that discussion specific.
An original delivery message could read: “The agreed files are in the folder linked below. Start with the delivery note, which identifies the approved exports and editable source. Please confirm that you can access the package and complete the review described in our project plan. The remaining client-owned item is the publication date.”
That message invites a concrete response without quietly adding a new promise of unlimited support.
Close with a clear support route
Restate the support arrangement already agreed: how questions should be sent, what is included and how further work will be discussed. If no arrangement exists, clarify it rather than inventing an end date or response guarantee at the last moment.
Keep your own project records according to the relevant agreement and retention requirements. Do not promise permanent storage unless you are prepared to provide it. Likewise, do not remove access or delete the only usable copy simply because the delivery email has been sent.
Our guide to freelance client boundaries covers the continuing relationship. A good handover supports that relationship by making the finished work understandable, usable and easy to distinguish from the next piece of work.