A good brief doesn’t just save time — it determines whether a project goes well or poorly. Most briefs I receive are either a paragraph long (“we need a new website, something modern”) or a 40-page deck with no clear priorities. Neither is ideal. The paragraph brief leads to misaligned scoping. The deck brief leads to a quoting process that takes twice as long as it should and still misses something.
This is a practical guide to briefing a WordPress developer well — what to include, what you don’t need to include, and a template you can copy and use today.
Why the brief matters more than most people realise
A brief isn’t just a formality before the real work starts. It’s doing several important jobs at once.
It forces clarity before money is spent. The process of writing a brief surfaces disagreements and gaps within your own team that would otherwise emerge mid-project. “Who is actually providing the copy?” and “do we have a brand guide?” are much cheaper questions to answer at brief stage than at build stage.
It’s the basis for accurate scoping. A developer who quotes from a one-paragraph brief is guessing. A developer who quotes from a well-structured brief is pricing actual work. Quotes that emerge from vague briefs either come in too high (because the developer has padded for unknowns) or too low (because they’ve missed something). Neither serves you.
It protects both sides when expectations drift. Projects change. Scope creeps. Stakeholders have opinions at launch they didn’t have at kickoff. A good brief is a shared reference point — the agreed definition of what was being built. When something outside that definition comes up, the brief is what makes that conversation straightforward rather than adversarial.
The quality of the brief often predicts the quality of the working relationship. This is something I’ve noticed consistently. Clients who write clear, considered briefs tend to be clear and considered throughout the project. Clients who brief vaguely tend to stay vague. It’s not a hard rule, but it’s a reliable signal.
What a good WordPress project brief actually includes
A useful brief doesn’t need to be long. It needs to be complete on the things that affect scoping and direction. Here’s what that means in practice.
Project overview
Start with what the site needs to do, not what it needs to look like. “We need a site that clearly explains our three service lines to marketing directors at mid-sized Ontario businesses, and converts them to a discovery call” is a useful brief opener. “We need something modern and clean with good UX” tells a developer almost nothing.
Three things worth covering in the overview:
- What the site needs to do — its functional purpose, not its aesthetic
- Who the audience is — primary, secondary if relevant; what they already know, what they need to be convinced of
- What success looks like 12 months after launch — more enquiries, better-qualified leads, lower bounce rate, ranking for specific terms. Naming the measure of success early shapes every subsequent decision.
Technical requirements
This is where most briefs go thin, and where the most expensive misunderstandings live.
CMS and editing needs. Who will update the site after launch, and what will they need to update? A marketing manager updating blog posts and team bios has different needs from a developer making structural changes. The answer shapes what kind of content management layer gets built.
Integrations. Does the site need to connect to anything? A CRM (HubSpot, Salesforce, others)? An email platform (Mailchimp, Klaviyo)? A booking system (Calendly, Jane App)? An e-commerce layer? Each integration adds scope. Not listing them in the brief means they get discovered later, which costs more.
Hosting. Is there an existing hosting arrangement, or does that need to be set up? Do you have a preference for hosting provider? Are there specific uptime or performance SLAs the host needs to meet?
Performance expectations. Is there a Core Web Vitals target? A specific load time the site needs to hit? If the site is for a regulated sector where load speed affects conversion — a dental clinic, a paralegal, a mortgage broker — this is worth naming explicitly. If there’s no specific target, saying so is also useful.
Design and brand
What brand assets exist. Logo files (preferably SVG), brand guidelines, typefaces, colour palette. If these don’t exist and need to be developed as part of the project, say so — it’s separate scope.
Design direction. Are you providing designs (Figma, Adobe XD) for the developer to build from? Is this a collaborative design-and-build engagement? Or are you expecting the developer to lead design? These are fundamentally different engagements with different timelines and costs.
Reference sites. Three to five URLs with notes on what specifically appeals — not “I like this site” but “I like how this site presents pricing” or “I like the navigation structure on this one.” The notes matter as much as the URLs.
Content
Who is providing copy. This is the question most briefs skip. If the client is providing copy, when? In what format? Who signs off on it? If a copywriter is involved, are they already engaged or does the developer need to recommend one? Copy delays are the most common cause of project delays — establishing this upfront is worth it.
Photography and imagery. Is there an existing asset library? Is a photography shoot planned? Is the expectation that stock imagery will be used? If the site will need custom illustration or iconography, who’s providing that?
Pages and content hierarchy. A rough sitemap — even a bulleted list of the main pages — is enormously useful. It establishes scope, surfaces structural questions early, and gives the developer something concrete to quote against.
Timeline and budget
Timeline. Is there a hard deadline (a conference, a product launch, a regulatory deadline) or a soft target? Hard deadlines affect how a project is staffed and sometimes what’s possible. Knowing early means planning appropriately rather than discovering constraints mid-project.
Budget. A rough range is significantly more useful than no number at all. “We have £15–20k for this” lets a developer scope to fit. “We don’t have a fixed budget” usually means the developer will either over-spec (quoting what the project deserves) or under-spec (quoting what they think will get through). Neither produces the right outcome.
You don’t have to commit to a number. A range is fine. “Under £10k” is useful. “Somewhere between £20–40k” is useful. Even “we’re not sure, but we know it’s not enterprise-scale” is more useful than silence.
What you don’t need to include
Over-speccing a brief is also a problem, just a less common one.
You don’t need to specify which plugins to use, which PHP version to target, or how the database should be structured. A good developer will make those decisions. Specifying them without the expertise to justify them creates friction rather than clarity.
You don’t need to have resolved every internal disagreement before you brief. If there’s genuine uncertainty about something — whether the site needs e-commerce, whether the blog will actually be maintained — say so. Noting open questions is more useful than papering over them.
You don’t need a complete sitemap or finished copy. A rough sense of scope is enough at brief stage. The detail gets filled in during kickoff and discovery.
A brief template you can use
Copy this, fill it in, send it. Download the brief.
Project overview
What does this site need to do? Who is the primary audience? What does success look like 12 months after launch?
Technical requirements
Who will update the site, and what will they need to update?
Integrations needed (CRM, email, booking, e-commerce, other):
Hosting: existing / to be arranged / no preference
Performance targets or requirements (if any):
Design and brand
Brand assets available: yes / partial / needs developing
Design direction: client providing designs / collaborative / developer-led
Reference sites (with notes on what specifically appeals):
Content
Copy provided by: client / copywriter (engaged / to be engaged) / developer to advise
Photography/imagery: existing library / shoot planned / stock / TBD
Rough page list or sitemap:
Timeline and budget
Hard deadline (if any):
Soft target launch date:
Budget range:
Open questions
Anything unresolved that the developer should know about:
The conversation that follows a good brief
A developer who has read your brief properly will come to the kickoff call with questions, not a presentation. The questions will be about the things the brief raised but didn’t resolve — the integrations that need more detail, the content timeline, the edge cases in the CMS requirements.
If a developer reads your brief and comes back with a quote the same day, they either have unusually deep experience in exactly your sector, or they’ve made a lot of assumptions. It’s worth asking which.
The kickoff call that follows a good brief tends to be faster and more substantive. You spend less time establishing basics and more time on decisions. The brief has done the work of aligning expectations so the call can move into planning.
If you’re evaluating a WordPress developer for an upcoming project, the work I do for agencies and direct clients starts with exactly this process. For agencies specifically, there’s more on how I work with agency partners and what that handoff looks like in practice.