Project Closeout Checklist and Archive Template for Freelancers

A project can be delivered and still remain mentally open. There are working files in a shared folder, an unanswered question about the final version, and a collaborator who still has access. A closeout note gives those loose ends a visible owner and leaves a usable record for the next person who needs the work.

The purpose is practical: identify what was delivered, what remains unresolved, where the retained files live, and who can reach them. This template is for a small freelance project. Adapt it to the agreement and systems you already use; it does not establish new commercial terms.

Name the version that is actually finished

Start with the latest accepted deliverable, not the entire working folder. Record its filename or version, its location, and the evidence of acceptance. If acceptance is still pending, label the project that way. Sending a link is not the same as receiving confirmation that the recipient has accepted the work.

For example, a designer might record a final PDF, editable source package, and export instructions as three separate items. An unfinished illustration should remain an open item with a next action, rather than disappearing inside a folder called final.

The earlier asynchronous handoff guide helps explain a deliverable. Closeout adds a different check: can someone understand the state of the entire project after the daily conversation has stopped?

Copy this closeout record

Create one document at the top of the project archive. Replace each bracketed prompt with a short answer. Keep links specific enough that they open the relevant file or record.

• Project and reference: [Name, client, internal project ID]
• Prepared by and date: [Name, date, time zone if relevant]
• Status: [Awaiting acceptance / accepted with open items / closed]
• Accepted deliverables: [Item, version, location, acceptance record]
• Working files included: [Source files and any instructions required to use them]
• Excluded material: [Drafts or assets that are outside the agreed handoff]
• Open items: [Issue, owner, next action, target date]
• Access and ownership: [System, owner, continuing users, changes still needed]
• Financial follow-up: [Reference to the existing invoice record and its current status]
• Archive location: [Primary location and how the retained copy is protected]
• Retention review: [Agreed review date or the person who will determine it]
• Future contact: [Where a question should go and any existing support arrangement]

Link to your ordinary invoice record instead of copying payment details into a broadly shared document. The same principle applies to passwords, recovery codes, and private client information: the closeout note should point to the appropriate controlled system.

Test the package from the recipient's perspective

Open the delivery location using the intended recipient's permissions where a safe test is possible. Check that the final export opens, filenames are understandable, and the source package includes the instructions you promised. Confirm that links do not lead to a private draft visible only to you.

A useful package has an obvious starting point. Add a short readme naming the final files, their purposes, and any required application. Avoid requiring the recipient to reconstruct the project from a sequence of chat messages or guess which numbered version was approved.

If something cannot yet be handed over, record the limitation and the person responsible for resolving it. The goal is a truthful record, not a page with every box marked complete.

Review access before calling the archive settled

List the places where access was granted: shared folders, a design tool, a project board, a hosting account, or a temporary review link. Separate continuing access from temporary access. Coordinate changes with the responsible owner so a tidy archive does not interrupt ongoing work.

Google Drive illustrates why this needs an actual check. Its folder-sharing guidance explains inherited permissions and circumstances in which a person can retain separately granted access to a file. Removing someone from one folder is therefore not a complete access audit. Use the controls and permission model of the service you are working in.

Record the change, the date, and any exception in the closeout note. Confirm that the intended owner can still open the retained files after changes are complete.

Keep a retrievable archive

Choose a consistent location and a short naming convention, such as project reference, delivery date, and version. Keep accepted exports separate from working material when that makes retrieval clearer. Do not delete drafts merely because the project is closed; first follow the retention arrangement that applies to the work.

A synchronized folder and an independent recoverable copy serve different purposes. Whatever storage arrangement you already use, verify that an important retained file can be found and opened from the recovery route. Record that check without turning the closeout note into a technical storage manual.

For a small project, one clear index is often enough. Adding elaborate tags and databases can create maintenance work without making the next retrieval any easier.

Send a short completion note

Use this as a starting point: “The agreed deliverables are available at [location], with the accepted versions listed in [closeout record]. The remaining item is [item], owned by [person], with the next action due [date]. Please use [contact] for follow-up under our existing arrangement.”

If acceptance is pending, say so directly and name the decision required. Once it arrives, update the status and link to the confirmation. Finish by recording one improvement for the next project in your client onboarding checklist, such as agreeing file ownership earlier or specifying the final export format. That turns a completed job into a better starting point for the next one.