Delivering final files to clients: a freelancer's handover that ends the 'can you resend that?' loop

Every freelancer knows the email. It arrives six months after the project closed, usually on a Friday: "Hi! Our printer needs the logo files again — can you resend?" The work takes four minutes. Finding the right version takes forty. And it is almost never the last time it happens, because the resend goes out the same way the original did — as an attachment the client will lose again.

Client delivery feels different from selling a download in a shop, but the failure modes are identical: scattered files, ambiguous versions, links that die, and a buyer — your client — who has no shelf to go back to. The fix is not a fancier portal. It is treating the handover itself as a small product you package once and deliver properly.

The handover is a product, not an attachment

An email attachment is a delivery method that expires socially long before it expires technically. It gets buried, forwarded without the context, saved to a downloads folder that gets cleaned, or trapped in a former employee's inbox. When that happens, you become the archive — unpaid, on call, forever.

Decide, before the final invoice, that the deliverable is a package: a named, complete, self-explanatory set of files that a stranger at the client's company could pick up cold and use. That one decision changes everything downstream. You stop sending "final_v3_REAL.pdf" and start shipping something that explains itself.

Name and package finals so a client can find them in six months

Most resend requests are really naming failures. The client has the file; they just cannot recognise it among forty exports. Package finals like this:

• One folder, one zip, one name. ClientName-Logo-Finals-2026-10.zip beats five separate attachments every time. If it is one file they download once, it is one file they can search for once.
• Inside, name by use, not by your process. logo-print-cmyk.pdf, logo-screen-rgb.svg, logo-social-square.png tell the client which one the printer wants. export-7-large.pdf tells them nothing.
• Include a one-page README inside the package. Which file is for what, the fonts and colours used, and — crucially — where the package itself lives if they need it again. A README inside the zip travels with the files when they get forwarded, copied to a shared drive, or handed to a new marketing hire.
• Keep drafts out. The finals package contains finals only. Every "almost" version you include doubles the chance the wrong one gets printed.

One delivery, one place: stop scattering finals across chat, email and drives

The average project ends with files in four places: mock-ups in chat, a proof in email, a large file on a transfer service that expired in seven days, and the real final… somewhere. When the client comes back, neither of you can reconstruct which link was the delivery.

Pick one canonical delivery point per project and say so in writing: "Your finals live at this link; that is the delivery of record." Other channels can discuss the work, but the delivery happens in exactly one place. Two rules make this stick:

1. The final-payment moment and the delivery moment are the same moment. If you sell deliverables as a paid package — a brand kit, a template set, a photo set, an illustration pack — delivering through the payment itself means the client cannot lose the receipt trail: payment, delivery email, and download all reference each other.
2. Never let a temporary transfer link be the only copy of the delivery. Expiring transfer links are fine for a quick proof. For finals, they guarantee a resend request on the day they die — and the client will experience that as your delivery failing, not their link expiring.

There is a second audience problem, too: you rarely deliver to one person. The founder approves, the marketing hire downloads, the printer asks questions, and an assistant does the searching six months later. A delivery that only makes sense to the person who sat through your review calls will fail everyone else. That is why the canonical delivery point matters more than the channel you chat in — chat threads belong to individuals, but a single delivery link or delivery email can be forwarded, bookmarked and searched by whoever inherits the project. When you hand over, name a human owner on the client side in the delivery message ("Delivered to Maya, for the marketing team") and invite them to forward the delivery email itself, not just the files. Forwarding the email preserves the version sentence, the README pointer and the re-download route; forwarding naked files strips all three. And if the client has a shared drive or asset library, ask them to file the whole package there the same day, while the project is still warm — a five-minute filing task at handover saves the fifty-minute archaeology session that otherwise lands on you, unpaid, two quarters later.

Proof, versions, and the line between draft and final

Half of all "wrong file" disputes are version disputes. Protect yourself with boring clarity:

• Watermark or label proofs as proofs; finals arrive clean, in one event. If a client can download something that looks final during review, they will use it, and the "unpaid final" conversation gets much harder.
• Version the package, not the panic. If a final changes after delivery, ship …-Finals-v2.zip as a complete replacement package and say, in the delivery message, "v2 replaces v1 entirely." Never send a single corrected file into the wild on its own — that is how v1's wrong logo ends up on a billboard.
• Write the delivery sentence. One line in the delivery email — "Delivered: logo finals v1, 6 files, [date]" — is your proof of what changed hands and when. When a scope argument starts three months later, that sentence ends it.

Expiry, revocation, and the awkward cases

Sometimes delivery needs an off switch, and it is better to design it before you need it:

• Preview access can expire; paid finals should not quietly vanish. Time-limit the review links if you like, but a client who paid in full and loses access because a link aged out will — reasonably — be furious. Know which of your links expire and say the expiry out loud at delivery, not in the small print.
• Revocation is for non-payment and licence breaches, not leverage. If an invoice is genuinely unpaid or a client uses files far outside the agreed licence, being able to revoke a download link and any licence key is a real protection. Using it mid-argument about revisions is how freelancers get reputations. Decide your line now, while nobody is angry.
• Keep your own archive regardless. Delivery is not backup. Keep the finals package, the delivery email, and the invoice together in your own storage for years; storage is cheap, and "the client lost it and so did I" is the one unforgivable ending.

The resend loop: make re-delivery self-serve, not a favour

You cannot stop clients losing files. You can stop each loss becoming your unpaid work. Aim for a delivery where the client's first move is going back to the delivery, not emailing you:

• The delivery email is the bookmark. Make its subject the search term the client will type later: the project name plus "final files — delivery". Clients search their inbox by your name and the project; meet them there.
• Say the quiet part in the delivery message. "If your team needs these again, use this same link/email rather than asking for a resend — it always points at the current finals." Clients ask for resends because they assume the original route is dead. Tell them it is not.
• Charge honestly for archaeology, not for clicks. If re-delivery is self-serve, the rare request that does reach you is real work — hunting a three-year-old project, re-exporting from dead software. Many freelancers write "re-issue of archived finals: fixed fee" into their terms. The fee is rarely collected; its job is to make clients keep the package safe in the first place.

Client final-file delivery checklist

• [ ] Finals packaged as one named zip (or one delivery page) — no loose attachments
• [ ] Files named by use (print/screen/social), not by export order
• [ ] One-page README inside the package: contents, usage, where to re-download
• [ ] Drafts and near-final versions excluded from the finals package
• [ ] Exactly one delivery of record, named in writing to the client
• [ ] No expiring transfer link is the only route to the finals
• [ ] Proofs clearly labelled; finals delivered clean, in one event
• [ ] Delivery email states contents, version and date in one sentence
• [ ] Link expiry and revocation terms said out loud at delivery, not buried
• [ ] Your own archive holds package + delivery email + invoice together
• [ ] Delivery email subject contains the words the client will search for later
• [ ] Terms include an archive re-issue fee, even if you never charge it

None of this needs new software habits so much as a decision: the handover is part of the work you are paid for, so it deserves the same care as the work itself. Package it once, deliver it in one place, and let the resend loop die of neglect.

Closing note: I help build FileFreight, a small, new tool for paid digital delivery — upload a file, share a buy link, and each buyer pays through your own Stripe account and gets a personal download link (with per-buyer PDF stamping and licence keys, and refund-triggered revocation). Honest fit for this topic: it suits deliverables you sell as a paid package; it is not a free client portal, proofing gallery, or project-management tool, and unpaid one-off handovers are not what it is for. Caveats: it is delivery only, not a marketplace and not a merchant of record — no sales-tax/VAT handling — there is no importer yet (the first 20 sellers get a free hand-done migration), and it is not a Shopify app. Pro is $19/mo at 0% per-sale fees; the free plan takes 5%.