The end of a freelance project has a way of getting messier than the project itself. Deliverables are scattered across email attachments, Slack messages, and shared drive links; the client isn’t sure what they actually received versus what’s still pending; and three weeks later you’re both digging through the same thread trying to find a file that got sent halfway through week two.
This is about replacing that thread with a single page — a clean, permanent record of what was delivered, what the client needs to know to maintain it, and how to reach you if something comes up.
Why the email thread approach fails
An email thread is optimized for the conversation that happened, not the reference material someone needs afterward. Six weeks after the project wraps, the client’s not going to scroll back through forty messages to find the login credentials you mentioned in message twelve. They need a single, organized place — and if it doesn’t exist, the fallback is emailing you again, which is exactly the ongoing entanglement a clean handoff is supposed to avoid.
What a handoff page actually needs
- A list of what was delivered, plainly — the site, the files, the credentials, whatever was actually part of scope.
- Links to everything — the live site, the repo if relevant, any shared assets — in one place instead of scattered across old messages.
- Basic maintenance instructions, if the client will be touching anything themselves — how to update content, who hosts it, what happens if something breaks.
- Your availability for follow-up work, stated clearly — are you open to a support retainer, or is this genuinely the end of the engagement?
Why this deserves its own page instead of a document
A Google Doc technically covers the same information, but a real page feels like a deliverable in its own right rather than an internal note — it’s something the client can bookmark, share with a teammate, and refer back to without needing an account or a shared-drive invite. Carrd works well for this specifically because it’s fast enough to build that it’s worth doing even for a modest project, and it reads as a polished final deliverable rather than a leftover document nobody organizes properly.
Structuring the handoff clearly
Organize by “what it is,” not by when it happened
A chronological list mirrors the project timeline, which nobody needs after the fact. Grouping by category instead — deliverables, credentials, next steps — matches how the client will actually look for something later: “where’s the login,” not “what happened in week three.”
Be explicit about what’s included and what isn’t
State clearly what was in scope and delivered, and just as clearly what wasn’t — hosting renewal, ongoing updates, future feature requests. This single section prevents more scope-creep disputes than any contract clause, because it’s the thing the client actually reads after the project ends.
Include one clear next step, if there is one
If there’s a genuine action the client needs to take (renew a domain, set up their own hosting account, review something), state it plainly with a deadline if relevant, rather than assuming it was covered adequately during a call weeks earlier.
What this does for you, not just the client
Beyond the client’s benefit, a handoff page is a clean closing artifact for you — a reference for what you delivered on this project, useful if a dispute ever comes up later, and a template you can reuse structure-for-structure on the next project, rather than reconstructing an ad hoc summary from memory each time.
Timing the handoff correctly
Send the page as part of the actual close of the project, not as an afterthought days later — ideally in the same message where you deliver final invoices or wrap-up notes. A handoff page that arrives promptly reinforces that the project ended in an organized way; one that trickles in a week after everyone’s mentally moved on undercuts the professionalism it was meant to convey.
What to skip
Skip an exhaustive technical changelog of every decision made during the project — that belongs in commit history or your own notes, not a client-facing summary. The client wants to know what they have and what to do with it, not a detailed narrative of the build process.
Quick checklist
- List every deliverable plainly, grouped by category, not by timeline.
- Link everything in one place — no digging through old messages.
- Include basic maintenance instructions if the client will touch anything themselves.
- State explicitly what’s in scope and what isn’t.
- Reuse the same structure for future projects instead of starting from scratch each time.
A good handoff page ends a project cleanly, for both sides — no lingering thread, no ambiguity about what was delivered, and nothing to dig for six weeks from now.
Tested firsthand
