How to Brief a Web Developer (So You Actually Get What You Pay For)

The number one reason web projects go badly isn’t a bad developer. It’s a vague brief. Without clear scope, even excellent developers will build something that misses what you actually needed.

Here’s the structure we wish every client used when briefing us, in the order each piece matters.

1. The one-sentence “why now”

Before features, before tech, before page count - why are you doing this?

“Our current site doesn’t reflect the business we are today.”
“We’re losing leads because the contact form doesn’t work properly.”
“We’re launching a new service line and the old site has no place for it.”
“We’re being outranked in Google and need to fix the SEO foundation.”

Whatever the answer is, write it down. It anchors every later decision. When a stakeholder later asks for an unrelated feature, you can compare it to this sentence and decide whether it fits.

2. Business context

A short paragraph the developer can read in 60 seconds:

What the business does
Roughly how big it is (revenue range, headcount)
Who the customer is
How customers find you today
What’s working and what isn’t

The developer’s job is to make a website that helps your specific business, not a generic one. This context shapes every recommendation they’ll make.

3. Goals - measurable, named

Three to five concrete goals, each with a number. Not “improve SEO” but “rank in the top 5 for these 8 specific keywords within 12 months.” Not “look more professional” but “convert at 2.5%+ from organic traffic” or “reduce time-to-first-quote to under 24 hours.”

If you can’t name a measurable goal, the project will succeed or fail on vibes. That’s the worst possible outcome.

Sample concrete goals:

“Increase qualified leads from the site by 50% in 6 months.”
“Reduce time-to-decision for prospects from 14 days to 7.”
“Rank in the top 3 for ‘X’ in Sydney within 12 months.”
“Cut hosting + maintenance cost by 40%.”
“Build internal tooling that saves 4 hours/week of admin time.”

4. Audience

Who is this site for, in concrete terms?

Their role / job title
Their context (in a hurry on mobile? researching at a desk?)
Their objection (what makes them hesitate to engage?)
Their decision criteria (what convinces them?)
Their language (industry jargon? plain English? technical specs?)

If you have multiple audiences (consumers + businesses, for example), describe each. Sites that try to talk to everyone end up resonating with no one.

5. Site map and key page intent

A list of the pages you think the site needs, with one sentence per page describing what the user should do on that page.

Example:

Home - Help a prospect understand what we do and book a consult.
About - Convince a prospect we’re trustworthy and competent.
Services / X - Detail service X enough that a qualified prospect submits a brief.
Case Studies - Provide proof for prospects who need it before engaging.
Insights / Blog - SEO content + thought leadership for prospects in research phase.
Contact - Reduce friction to enquiry submission.

This pre-thinking saves weeks of “what about a page for…?” conversations later.

6. Content readiness

The honest answer to: do you have the content for this site, and who will write it?

The single biggest cause of project slippage we see is content that wasn’t ready when the design needed it. Resolve this before the project starts:

“We have current copy that’s mostly fine - minor edits.”
“We have draft copy that needs polish - content team has it scheduled.”
“We have nothing - we’d like the agency to write or recommend a writer.”
“We have content but it’s all wrong - we’ll rewrite as part of the project.”

Each of those has different time and cost implications. Be honest. “We’ll write it ourselves while you’re building” is usually fantasy - your team is busy with their actual jobs.

7. Functional requirements

The features the site needs, listed plainly. Avoid jargon and “best practice” boilerplate. Specifics, not aspirations.

“Contact form with the following fields: name, email, phone, service type (dropdown), message. Submissions go to [email protected] and also sync to our HubSpot CRM.”
“Newsletter signup that adds the subscriber to our Brevo list ‘Insights Subscribers’.”
“Blog where two team members can publish without needing a developer’s help.”
“Book-a-consult button that opens a Calendly widget.”
“Online quoting tool - user enters address and project type, gets an indicative price range.”

The more specific each requirement, the more accurately it can be quoted and built.

8. Integrations

The other systems the site will talk to. Examples:

CRM: HubSpot, Salesforce, Pipedrive, Brevo
Email marketing: Mailchimp, Brevo, Campaign Monitor
Calendars: Calendly, Acuity, Cal.com
Payments: Stripe, Square, PayPal
Accounting: Xero, MYOB
Analytics: GA4, Hotjar, Plausible
Other: anything bespoke

For each, note:

What needs to happen (sync contacts, sync sales, sync calendar slots)
Who has API access (the developer will need it)
Any constraints (rate limits, data residency)

9. Technical preferences and constraints

Optional but useful:

“We’d like to be able to edit content ourselves without a developer.”
“We currently host on WP Engine and would prefer to stay there.”
“Our IT team requires SSO via Azure AD for any admin areas.”
“The site must be accessible to WCAG 2.1 AA.”
“We don’t want to be locked into a proprietary platform.”

If you have no preferences, say so. That gives the developer freedom to recommend what fits.

10. Inspiration and anti-inspiration

Three sites that, for any reason, you admire. Three sites that, for any reason, you don’t want to look like.

Don’t just send screenshots. Explain what about each you do or don’t like. “We like the typography on this site” is useful. “We like this site” is not.

This piece, more than any other, calibrates the designer’s instincts to your taste.

11. Budget - a range, honestly

A real budget range, not a wish. “$15,000 to $25,000” is useful. “We’re flexible” is not.

If your budget is firm at $10,000 and the scope you’ve described needs $25,000, the developer needs to know. They can either:

Scope down to what fits the budget (cut features, simplify design, defer phase 2)
Decline politely and recommend someone whose pricing fits
Suggest a phased approach

Hiding the budget produces quotes that miss reality. Sharing it produces real conversations about value.

12. Timeline and constraints

When does it need to launch, and why? Real constraints (trade show, product launch, end of financial year) are workable. Manufactured urgency (“ASAP”) is just stress.

If the timeline is genuinely tight, name the trade-off you’re willing to make:

“Tight launch - willing to cut features.”
“Tight launch - willing to launch on a simpler platform.”
“Tight launch - willing to increase budget for additional resourcing.”

A developer can’t optimise all three of scope, time, and cost. Tell them which to flex.

13. Decision-makers and process

Who needs to approve what? Examples:

“Design approval: CEO and head of marketing, joint sign-off.”
“Copy approval: head of marketing, sole sign-off.”
“Final go-live: CEO.”

And:

“We can turn around feedback within 48 hours.”
“Our reviewer is on leave 12–26 of [month] - plan around that.”

This single piece prevents many timeline slips. The agency knows who to chase and when.

14. What’s out of scope

The thing you’re not asking for. This is as important as what you are asking for.

“Not redesigning the email templates.”
“Not migrating the careers page yet.”
“Not building the customer portal - that’s a separate project.”
“Not adding e-commerce now, but we want to in 12 months - design with that in mind.”

What a good brief looks like in practice

A complete brief, written this way, is usually 2–4 pages. It can be a Google Doc, a PDF, an email - format doesn’t matter. What matters is that someone outside your team could read it and produce a useful first response.

If you can write this brief, you’ll get:

Accurate, comparable quotes from different agencies
A faster discovery phase (or even skip parts of it)
A clearer contract and scope
Less conflict during the build
A site that hits the goals you named

If you can’t write this brief, you’re not ready to hire yet. Write it first.

The questions to ask if you’re stuck

If you find yourself unable to answer parts of this, it usually means one of:

You don’t know who your customer is yet. Spend time on this before any design happens.
You don’t have clear business goals. Same - the website serves the goals, not the other way around.
You’re outsourcing strategy. Some of this is fine to delegate, but the goals and audience should never be invented by the developer.
You don’t have stakeholder alignment. Have the hard conversation internally before bringing in an agency.

The brief is, in a way, the cheapest part of the whole project. Get it right and the rest gets a lot easier.

Want a brief template? Get in touch and we’ll send you the exact one-page brief we use with new clients. No catch.