Agency Handoff Checklist: What to Give Your WordPress Developer

On this page

1. 1. Final design files, including every state
2. 2. Assets, fonts and licences
3. 3. Final copy and the sitemap
4. 4. Functionality notes and integrations
5. 5. Hosting and account access
6. 6. Acceptance criteria and a browser and device list
7. 7. Timeline and review rounds

When an agency outsources a WordPress build, most delays don't come from the code. They come from missing pieces: a font nobody licensed, a form nobody specified, hosting access that arrives a week late. This checklist covers everything to hand your development partner once the project is sold and the design is approved. It's different from the website brief template, which helps a business get an accurate quote; this is the full package for a project that's ready to build.

1. Final design files, including every state

• One approved Figma or XD file, with final frames clearly labelled and explorations archived or moved to a separate page
• Desktop and mobile frames for every page, and tablet frames where layouts are complex
• Interactive states: hover, focus and active for buttons and links, open menus and dropdowns, and sticky header behaviour
• Form states: validation errors, success messages and disabled buttons
• Easily forgotten templates: blog post, blog archive, search results, 404 page, legal pages and, for stores, product, category, cart and checkout
• Empty states: no search results, an empty cart, a category with no posts yet
• Inspect or Dev Mode access for the developer

How the file itself should be set up, with styles, components and spacing, is covered in the Figma to WordPress handoff guide. Share it with your designers.

2. Assets, fonts and licences

• Logos and icons as SVG, plus a favicon
• Photos at full resolution; the developer will resize and compress them
• Video files or embed links, and any animation files
• Fonts: Google Fonts names, or font files with a web licence that covers the client's domain. A desktop licence bought for design work doesn't always cover web use, so check the foundry's terms.
• Stock images: licence details, and who holds each licence
• Premium themes and plugins: who buys them, and whether licences sit in the client's name or the agency's

Licensing gaps tend to surface after launch, when they're awkward to fix, so settle them in the handoff.

3. Final copy and the sitemap

• Approved copy for every page, in a document that uses the same section names as the design
• SEO titles and meta descriptions, if your agency writes them
• A sitemap: every page, its URL slug, its parent page, and the header and footer menus
• For redesigns: a redirect map listing old URLs and their new equivalents
• Content entry: who adds content (the developer, your team or the client), including any blog posts or products being migrated

If copy isn't final, say which pages will change and roughly by how much. Long headings and extra paragraphs can break layouts that looked fine with placeholder text.

4. Functionality notes and integrations

Item	What to specify
Forms	Fields, which are required, who receives notifications, autoresponder text and the thank-you page
Integrations	CRM, email marketing, booking, payments, WhatsApp and maps, with accounts or API access ready
Tracking	Google Analytics 4, Tag Manager, ad pixels and the events to track
Plugins	Any the client already pays for or insists on, and any to avoid
Editing	Which sections the client must be able to edit, and whether they expect Elementor or the block editor
Special features	Multilingual content, filters, calculators, member areas or store rules
Animations	What moves, when, and on which devices

The editing question shapes the whole build approach; see page builder, block theme or custom theme.

5. Hosting and account access

• Staging: agree where the site is built: the partner's staging server, yours or the client's hosting
• Hosting: access to the client's hosting for launch, or a decision on who sets it up
• Domain and DNS: usually needed only at launch, but find out early who controls them
• Third-party accounts: Analytics, Tag Manager, Search Console, reCAPTCHA, email sending (SMTP) and any integration logins
• Existing site: for redesigns, admin access and a recent backup

Share credentials through a password manager rather than chat or email, and create separate user accounts for the partner instead of passing on the client's own login.

6. Acceptance criteria and a browser and device list

Agree what "done" means before the build starts, not during review:

• Design fidelity: what counts as a match, and how small differences between design tool and browser rendering are handled
• Browsers and devices: a written list, such as current Chrome, Safari, Firefox and Edge, plus an iPhone and an Android phone, and anything else the client's audience relies on
• Performance: which key pages will be tested in PageSpeed Insights, and what result is expected
• Accessibility: a baseline such as keyboard navigation, readable contrast, alt text and labelled form fields
• SEO basics: titles, headings, redirects and the XML sitemap
• Out of scope: anything the client might assume is included

7. Timeline and review rounds

1. A kick-off call to walk through the handoff and answer questions
2. The homepage or first key template, built for early feedback
3. The remaining pages, built on staging
4. Your agency's internal QA
5. A client review round, with consolidated feedback
6. Fixes, a final check and launch

State how many review rounds are included, how feedback is delivered (one consolidated list, with screenshots) and the response time each side commits to. Name one contact on each side, and agree overlapping working hours if you're in different time zones. Build in a buffer, because content and client approvals are what most often slip. Sharing how to give clear website feedback with your clients helps keep each round focused.

I build WordPress sites from Figma for agencies, white-label and behind your brand. See Figma to WordPress and WordPress development for agencies.