1. Access first
The fastest way to lose a day is to send the brief without the access. Before the kick-off, prepare what the developer needs to start.
- A staging site, never the production site, with an admin account for the developer.
- Hosting or repository access if the work touches code or deployment, and a note on where the code lives.
- The list of plugins in use, and licences that need to be activated or are held by the agency.
- Any third-party accounts the build depends on, such as form services, mail tools or map keys.
2. State the real condition of the design
Say whether the design is approved and final, or still moving. A file marked "final" that changes during the build is the most common source of extra rounds.
Check that the file defines what the build will need: desktop and mobile layouts, tablet where the layout changes, hover and interaction states, and exportable assets. If something is not defined, say so in the brief instead of leaving it to be discovered. The design handoff guide goes through this in detail.
3. Define the scope in pages, templates and behaviours
List what is included as concretely as you can: number of pages, templates, custom post types, forms, integrations, languages. A line like "build the site" is not a scope.
Equally useful is a short list of what is out: copywriting, content entry, SEO setup, migration of existing content, or anything else you will handle yourself. It prevents the quiet assumption that the developer will do it.
4. Write acceptance criteria
Acceptance criteria turn "looks right" into something checkable. They do not need to be long.
- The pages and templates that must match the design, and at which widths.
- The browsers and devices you will test on.
- Behaviours that must work: forms submitting, filters, menus, language switch.
- Any performance or accessibility expectation the client has stated.
5. Say what content is real
Placeholder content hides problems that real content exposes: long titles, missing images, text in another language. If real content exists, share it. If it does not, tell the developer which sections will change and who will provide the content.
6. Agree on communication before you start
Name one contact on your side who answers questions and consolidates feedback. Two people giving different feedback on the same page is a frequent cause of rework.
Agree the channel you already use, whether Slack, email or a ticket tool, and how often you expect updates. Short, written status updates are usually enough, with a call reserved for the kick-off or for a complex handover.
7. Plan revisions on purpose
Decide how many feedback rounds the estimate covers, how feedback is delivered (one consolidated list, not scattered messages), and what happens when a request changes the scope. Writing this down is not about distrust; it keeps the estimate honest for both sides.
8. Include dates and dependencies
State when the work needs to be online and what it depends on: client approvals, content delivery, a third-party launch. A fixed date with unresolved dependencies is a risk you want the developer to know about on day one.
9. A brief you can copy
Paste this into an email or a ticket and fill in each line. If you cannot fill one, that is useful information too.
- Project and goal, in two sentences.
- Staging URL, admin access, repository, plugin list.
- Design file link and its status: final or in progress.
- Scope: pages, templates, forms, integrations, languages. Out of scope: listed.
- Acceptance criteria: widths, browsers, behaviours that must work.
- Content: real or placeholder, and who provides it.
- Contact on your side, channel, update rhythm.
- Feedback rounds included and how feedback is delivered.
- Deadline and dependencies.
Frequently asked questions
How detailed should the first brief be?
Detailed enough for the developer to give an estimate without guessing. A rough brief with staging access and the design is better than a perfect brief that arrives later. Gaps can be closed in a short call.
What if the design is not complete yet?
Say so, and list which parts are final. The build can start on the stable sections while the rest is finished, as long as the changes are tracked and the scope is updated.
Do I need a call to brief a freelancer?
Not always. A written brief with the access and the design is often enough. A short call helps when the scope is large, the design has gaps or there are integrations to discuss.
Next step
Ready to send a brief?
Send the project, the design and the staging access, and I tell you within 24 working hours whether I can step in.
Hire a freelance WordPress developer