Launch Is a Handover: The Client-Ready Checklist for Agencies

Summary

Most launch advice treats a website like a one-time event. For an agency, every launch is a handover, and repeatability matters more than a perfect launch day. This article gives you a pre-handover checklist built for managing multiple client projects. It covers setting a hard handover date, locking content early, testing from the client's perspective, scoping checks by site type, and running security, SEO, and runbook gates. The final step is a 48-hour follow-up that feeds lessons back into the next project. Use this as a living checklist, not a copy-paste list.

Most launch advice is written for one website, which is why it fails inside an agency. It assumes you have unlimited time to test every page. You don't. You have multiple projects in flight, a client who changed the phone number twice, and a stakeholder who keeps emailing about one small thing. The advice that works treats launch as a handover, not an event. Your real product is a repeatable process that produces a website the client can live in without calling you in a panic. This checklist is that process, built for agencies that must run the same quality gate across different clients, budgets, and site types. Use it as a backbone, not a one-size-fits-all list to copy.

Write the handover date first

Put the handover date on the calendar before you pick a template. Name it client-ready instead of launch. Then work backward: content deadline, design review, testing window, and a real buffer because the client will slip by at least two days. Write the date where everyone can see it.

If there is no date, scope creep has no anchor. When a client asks for one more page, you can say it moves the handover date. If the date already exists, the trade-off is visible; if it doesn't, every small ask is free and every deadline is fiction. An agency that cannot name a handover date cannot protect its margins. When you start from a vague brief, a repeatable agency process keeps this conversation the same on every project.

Lock the content that can't be improvised

Content is where client sites fall apart, not in code. A developer can build a page; they cannot invent the client's actual address, pricing, or team bios. Set a hard content deadline before design sign-off and make it as firm as the handover date.

Use one standard intake form on every project. Ask for phone, email, physical address, business hours, and the three services the client wants to sell. One client will give you a phone number that routes to a fax machine; another will hand you a logo saved as a Word document. Catching those during content collection is cheaper than catching them in the footer of a live site.

If one piece is missing at the deadline, publish with a clearly marked placeholder instead of freezing the project. A placeholder with a deadline beats a stalled build. The common failure is treating content as something that can be added later, which is how you launch a site with the wrong map pinned or a service the client stopped offering six months ago. Planning and information architecture exist to force these decisions before the build.

Test like the client on a bad day

You have stared at the site for weeks, so you see what you expect. The client sees what is actually on the screen. Open the site in an incognito window with a fresh session and run a pass with fresh eyes.

Click every link you can see, not just the ones you remember. Submit every form, and test the failure states, not just the success path. Load the site on a phone, on a slow connection, and with the menu open. Check that the phone number in the header matches the one on the contact page.

This is where small delays become stories. A hero image that loads slowly, a button that leads nowhere, a sticky header that covers the phone number on mobile—any of these frames the client's first impression. You don't need a hundred checks; you need the few that would be impossible to explain. A typo in a blog post is fixable; a broken checkout is not. If you run the same test on every client, you stop spending the first week after launch answering button-doesn't-work emails.

Scope the gate to the site

Run a scoping pass on every project before you run any checklist. A four-page brochure site and a store catalog are not the same project. Applying identical checks to both is either over-engineering or under-testing. Before you run the checklist, decide which checks matter for this client.

Site type	Non-negotiable checks
Brochure site	Client-perspective pass, contact details, SSL, basic SEO
Landing page	Load time, form submission, thank-you page, analytics
E-commerce	Checkout path, payment test, product images, backups

Keep the common gate—handover date, security, runbook, follow-up—and add the checks that protect this specific client. Skip the scoping step and you will spend your Friday testing a services page while the client's real worry is a checkout that will not process. Or you will launch an e-commerce site without testing the payment flow, and the client will not find out until a customer's order disappears.

Build the security gate once, run it every time

Security is where agencies drift. You do a full audit for the e-commerce client, then skip the brochure site because they do not collect data. That is the wrong instinct. UpGuard's website security guidance puts the same practices on every site: keep the platform updated, enforce strong authentication, limit user privileges, back up regularly, and serve everything over SSL/TLS. A brochure site can still be compromised; a client's domain can still be used to send spam.

Build one shared security checklist and run it on every project. Multi-factor authentication enabled for every login. Software and plugins updated. A backup that was actually tested, not just scheduled. SSL/TLS certificate installed and live. User privileges limited to what each person needs.

Make security a yes/no gate. If any answer is not yet, the site is not client-ready. Run the gate in staging before launch week, because certificate failures on launch night are emergencies you cannot bill for. Keep the list small enough that every item means something. If an item always passes, automate it or fold it into your build tooling. The cost of skipping it is not abstract; it is the middle-of-the-night message from a client whose site got defaced.

Make SEO a check, not a hope

Here is a launch you have seen: the site goes live, the design looks clean, and a month later the client asks why they do not show up on Google. SEO on a small site feels like a future problem, so it gets skipped. Digital Marketing Institute's beginner SEO guide treats technical setup as part of the basics, not marketing fluff: HTTPS, an XML sitemap, and a robots.txt file that lets search engines in.

Add an SEO section to your handover checklist and make it concrete. Confirm a title tag and meta description for every key page. Make sure each page has at least one piece of real text content, not just images. Generate an XML sitemap and submit it. Verify robots.txt is not blocking the pages you want indexed.

None of this is expensive. All of it is tedious, which is why it gets skipped. The cost is invisible for a few weeks, then you get the call: why does my business not show up on Google? You cannot answer that with a handover check; you can only answer it with proof that the basics were in place before the site went live. For the full setup, launch a no-code website that ranks from day one. At the very least, make the SEO gate a yes/no list so we will do SEO later cannot slither into the project.

Hand over the keys with a runbook

The handover is not complete when the site goes live. It is complete when the client can log in without calling you. A link and a password is not a handover; it is a first homework assignment. The client will find the settings page, experiment, and either break something or call you with a question you could have answered in a one-page document.

Write a runbook. How to log in and change the homepage text. How to swap an image. Where the domain and hosting live. When the domain renews and who is responsible for it. The ICANN domain registration process requires working contact information tied to the owner. If the client owns the domain, they need to know where the account lives and what happens if it expires. Put the renewal date in the runbook; you do not want the first post-launch call to be our website is gone because no one renewed the domain.

The runbook can be one page. It does not need to be a manual. But it must exist, and the client must open it while you are still on the call.

Follow up in 48 hours

A client goes quiet for a week after launch. You assume they are happy. Then the invoice email arrives, and you realize they spent six days not knowing how to update their own prices. The most useful test happens after handover, not before.

Forty-eight hours after the site goes live, send a short note. Ask one specific question, not everything okay? Specific prompts surface real answers. Did you try logging in? Does the contact form show up in your inbox? Is the address on the footer correct? Log what the client reports back and add it to the next project's checklist.

This is the moment where you catch what you could not have caught: the client's real phone number, their actual product images, the integration that only works with their data. Each time a client exposes a gap, add it to the next handover gate. That is how the checklist stays alive instead of becoming a document nobody reads. If you are looking for the bigger system, the client site maintenance maturity model starts where this follow-up ends.

A gate, not a trophy

The goal is not to have the most thorough checklist in the industry. It is to have a gate that catches the problems you actually see across your clients. That means pruning. If a check has not caught a single issue in your last several launches, either you have automated it or it is noise. A checklist full of items that always pass gives you a false sense of completion. The checks that matter are the ones that occasionally fail, because those are the ones preventing the embarrassing calls.

Do not add checks to feel process-rich. Add them only when they earn their place. The best launch checklist for an agency is shorter than you think: handover date set, content locked, client-perspective test passed, security and SEO gates green, runbook handed over, 48-hour follow-up scheduled. When that gate exists, launch stops being a moment of dread and becomes a formality. That is the difference between an agency that builds websites and an agency that delivers them.