Copy it. Fill it in. Send it with the project. No email required.
How many times has a client website stalled because someone was waiting on a login? Or a logo file? Or an answer to a question nobody wrote down?
Here’s the thing. Most website delays don’t start in the build. They start in the handoff. Missing files, fuzzy scope, and a “we’ll figure it out” launch plan. Next thing you know, you’re three weeks into back and forth, and your client is waiting.
This checklist fixes the handoff. Use it any time you pass a client site to a developer, a white-label partner, or a new person on your team. It’s built for small agency owners who still do client work and don’t have time to chase details twice.
1. The one-page project brief
Copy this block into a doc or your project tool. Fill in every line. If you can’t answer a line, that’s a question for your client before work starts, not after.
Client name:
Client website (current):
Project type: (new site / redesign / landing page / fixes)
Platform: (WordPress, Webflow, GoHighLevel, Shopify, other)
What this site needs to do (one sentence):
Who it’s for (the client’s customer):
The one action we want visitors to take:
Pages in scope (list each one):
Pages NOT in scope:
Example sites the client likes (links) and what they like about each:
Example sites the client does NOT like and why:
Who approves the work (name + email):
Who answers content questions (name + email):
Target launch date (and is it fixed or flexible?):
Anything that must not change (URLs, forms, tracking, integrations):
Notes:
2. Assets checklist
Gather these before kickoff. Put them in one shared folder with clear file names.
- Logo files (vector if they have it: SVG, AI, or EPS, plus a PNG with a clear background)
- Brand colors (hex codes) and fonts (names, plus license info if the font is paid)
- Final page copy, one file per page, marked “final”
- Photos and video, with permission to use them on the web
- Testimonials and reviews the client has approved for use
- Legal pages: privacy policy, terms, any required disclaimers
- Form details: what each form asks, and where each submission goes
- List of integrations: CRM, email tool, booking calendar, chat, payment
Tip: if copy isn’t final, say so in writing. “Draft copy, build with it, swap later” is fine. Just don’t let the developer guess.
3. Access checklist (without emailing passwords)
Never paste passwords into email or chat. Add the developer as a user with their own login, or share through a password manager. When the project ends, remove the access.
- Website platform. Add the developer as their own user. On WordPress, an Administrator can change plugins, themes, and settings. An Editor can only manage content. Give the lowest role that gets the job done. (WordPress: Roles and Capabilities)
- Hosting. Only if the work needs it (server changes, backups, staging). Many hosts let you add a separate user.
- Domain and DNS. Only at launch, and only if records need to change. Write down the current records before anyone touches them.
- Google Analytics. Add the developer by email with the role they need. (Google: Add and manage Analytics users)
- Google Search Console. Add as a user, not an owner, unless they need owner tools. (Google: Managing owners, users, and permissions)
- Form, CRM, and email tools. Only the ones the site connects to.
- Removal date. Write down when each login gets removed.
4. Scope questions to answer before work starts
These ten questions catch most of the surprises. Ask them once, write the answers in the brief, and you skip a lot of back and forth later.
- How many rounds of changes are included for each page?
- Who writes the copy? Who writes the alt text and page titles?
- Does the site need to work in more than one language?
- Are we moving old pages? If yes, which old URLs need to point to new ones?
- What forms are on the site, and where does each one send its data?
- Is there a blog or anything the client will update on their own?
- Does anyone need training on how to edit the site after launch?
- Are there any accessibility requirements from the client’s industry?
- Who pays for plugins, themes, fonts, or stock photos?
- Who looks after the site after launch: updates, backups, fixes?
5. Review steps
- Review on a staging link, not the live site
- One person collects all feedback and sends it in one list
- Each note says the page, the spot, and the change (“Home, second section, make the button say Book a Call”)
- Screenshots for anything visual
- Separate “must fix” from “nice to have”
- Client signs off in writing before launch
6. Launch checks
- Full backup of the old site saved
- Every form tested end to end (submit it, and confirm the email or CRM entry shows up)
- Old URLs redirect to the right new pages
- Page titles and descriptions filled in on every page
- The site isn’t blocked from search engines (a common leftover from staging)
- Analytics and tracking tags firing on the live site
- Checked on a phone, a tablet, and a desktop
- Links checked, no broken pages
- SSL working (the lock icon shows on every page)
- Temporary logins removed
Want someone to take the build off your plate?
That’s what we do for agencies. You hand off the work and get your time back. The same developers, designers, and technical Virtual Assistants work on your projects in an actual office, and they get to know you and how you like things done.
