What Happens After a Website Launches? The Handover Nobody Talks About

The site is live. The client is happy. You close the project in your tracker, send the final invoice, and move on to the next build.

Three months later: “Hey, what was the login for the CMS again?” Six months later: “My developer needs the specs for the contact form integration. Can you send those?” A year later: “We’re doing a redesign. Do you have the original files?”

Each of these emails takes 10-30 minutes of your time. Unpaid. Unplanned. And entirely preventable.

The handover is the most underrated step in the entire web design process. It’s the last thing the client experiences with you. It shapes whether they refer you, rehire you, or forget you.

Why most designers skip it

Three reasons.

Project fatigue. By the time you’ve launched the site, you’ve been looking at it for weeks. You want to move on. The handover feels like one more task on a project you’re ready to close.

No standard process. You’ve never had a handover template. You don’t know what to include. So you send a quick email with the CMS login and call it done.

It feels like extra work for no pay. The project is invoiced. The site is live. Writing documentation feels like working for free.

All three of these are valid feelings and all three of them are wrong. The handover takes 30 minutes when you have a process. It prevents hours of unpaid support later. And it’s the single best tool for earning referrals.

What a proper handover includes

A handover is a permanent document that answers every question the client will have about their website after you’re done.

Project summary

A brief description of what was built. “Designed and developed a 5-page responsive website on WordPress with CMS integration, contact form, newsletter signup, and multi-language support.” This reminds the client (and their future developer) what the original scope was.

Site structure

Every page that was delivered. Homepage, About, Services, Portfolio, Contact. Listed clearly so the client knows exactly what exists.

If you built custom templates or components, note which pages use them. “The Portfolio page uses a custom grid template that pulls from the Portfolio custom post type.” This information is gold for whoever maintains the site after you.

Features included

List every feature that was implemented. Live chat integration, newsletter signup, contact forms, search functionality, payment processing, multi-language support, events calendar. Each one is a deliverable you completed.

This list does double duty. It documents your work (useful if there’s ever a dispute about what was delivered) and it gives the client a reference for what their site can do. Clients forget features. They’ll come back and ask for something that already exists if you don’t document it.

Tech stack

What CMS was used. What plugins or integrations are installed. What analytics is set up. What email service is connected. What hosting the site runs on.

For each major component, note the version and any relevant configuration details. “WordPress 6.x, Elementor Pro 3.x, WooCommerce 8.x, Yoast SEO.” This helps the client’s future developer understand the environment without reverse-engineering it.

Maintenance checklist

What does the client need to do to keep the site healthy? This is the section they’ll reference most.

“Update WordPress core and plugins once a month.” “Review and respond to contact form submissions weekly.” “Back up the database before any major update.” “Renew SSL certificate annually.” “Monitor site speed quarterly using Google PageSpeed Insights.”

Each item should have a frequency and a one-line description. Keep it simple. The client is not a developer. They need to know what to do and how often, not the technical details of why.

Training notes (if applicable)

If you walked the client through the CMS, include a summary of what you covered. “How to edit page content. How to add blog posts. How to update the navigation menu. How to manage WooCommerce products.”

If you recorded a walkthrough video, include the link here. Video tutorials are the highest-value handover asset because the client can rewatch them whenever they’re stuck.

Credentials

This is sensitive. Don’t list passwords in the handover document.

Instead, note which accounts exist and how to access them. “CMS access: credentials sent via [secure method] on [date].” “Hosting dashboard: [provider name], login with your account email.” “Analytics: connected to your Google account.”

If you used a password manager during the project, transfer the relevant credentials to the client’s own manager. Don’t leave them in your account.

The handover nobody deletes

Here’s the key insight: the format matters as much as the content.

If you email the handover as a PDF, it will get lost. The client will search for it in six months, not find it, and email you instead. You’ll dig through your own sent folder, find the PDF, resend it, and spend 20 minutes on something that should have taken zero.

If you email it as a Google Doc link, it might get lost in their bookmarks. Better than a PDF, but still depends on the client being organized.

The ideal handover lives at a permanent URL that the client already knows. The same project portal they’ve been using throughout the build. They don’t need to find a new link. They don’t need to search their email. They go to their portal URL and the handover is there. Always. Permanently.

This permanent accessibility is what turns a handover from a document into a service. The client can reference it anytime. They can share it with their new developer. They can check the maintenance schedule a year later. Zero effort from you after you publish it.

The 30-day warranty window

Include your warranty terms in the handover. “For 30 days after launch, I’ll fix any bugs or defects in the delivered work at no additional cost. This covers: broken functionality, display issues across browsers, and errors in the code I wrote. This does not cover: third-party service changes, hosting issues, content edits by the client, or new feature requests.”

Being explicit about the warranty in the handover document prevents the “but I thought you’d fix that” conversation. The client knows exactly what’s covered and for how long.

After the warranty: maintenance retainers

The handover is also the natural moment to offer ongoing support.

“If you’d like ongoing maintenance, I offer a monthly retainer that covers: plugin and CMS updates, monthly backups, uptime monitoring, and up to 2 hours of content changes per month. [Contact me] to set this up.”

Don’t hard-sell it. Plant the seed in the handover document. The client will come back to it when they realize they need help. And when they do, they’ll come to you because you’re the person whose handover document they’ve been referencing for months.

The handover earns referrals

The last experience a client has with you is disproportionately memorable. Psychologists call it the peak-end rule. People judge an experience by how they felt at the most intense moment and at the end.

A polished handover signals that you care about the client’s success beyond the invoice. It tells them: this person is organized, thorough, and invested in my project even after they’ve been paid.

That feeling generates referrals. Not a “please refer me” email. Not a referral discount. The quality of the handover itself.

debrieft generates a permanent handover hub for every project. Site structure, features, deliverables, maintenance checklist, and training notes, all at a URL your client already knows. Your client gets a portal. You get a dashboard. Both in sync. Try it free at debrieft.app