How to Write a Brief for Your Web Developer

The quality of a website project is often decided before a single line of code is written.

I’ve been on both sides of this, as the developer receiving briefs and as the consultant helping clients scope their projects. The pattern is consistent: clear briefs produce good websites. Vague briefs produce frustration, scope creep, and results that don’t match expectations.

A brief isn’t a contract or a technical specification. It’s a conversation starter: a document that tells your developer what you need, why you need it, and what success looks like. The better the brief, the less time (and money) gets wasted on misunderstandings.

Here’s what to include.

Section 1: About Your Business

Your developer needs context. They’re not just building a website. They’re building a tool for your business. The more they understand your business, the better decisions they’ll make.

Include:

What your business does (one paragraph)
Who your customers are
What makes you different from competitors
Your business goals for the next 1–2 years

Example:

We’re a residential landscaping company in Austin, TX, serving homeowners in the central Austin area. Our customers are typically homeowners aged 30–55 who want a maintained outdoor space but don’t have time to do it themselves. We specialize in native Texas plants and drought-resistant designs. We’re looking to grow from 50 to 100 recurring clients over the next year.

That paragraph tells the developer more than a 10-page requirements document. It tells them the audience (homeowners, not commercial clients), the geography (Austin, relevant for local SEO), the differentiator (native plants), and the business goal (growth).

Section 2: What You Need the Website to Do

Not what it should look like, but what it should do. This is the most important section, and it’s where most briefs fail by being either too vague or too prescriptive.

Be Specific About Functionality

Too vague: “We need a modern website.”

Too prescriptive: “We need a hero section with a parallax background, a rotating carousel with 5 slides, a grid layout with 3 columns…”

Just right: “We need visitors to be able to see our services, view examples of our work, read customer reviews, and request a free estimate through a contact form.”

The “just right” version tells the developer what the site needs to accomplish without dictating how. It gives them room to propose the best solution while keeping you aligned on outcomes.

List Your Must-Haves and Nice-to-Haves

Separate what’s essential from what’s aspirational:

Must-haves:

Service descriptions for each service we offer
Photo gallery of completed projects
Contact form that sends to our email
Mobile-friendly design
Shows up in Google search results

Nice-to-haves:

Online booking for consultations
Blog for seasonal landscaping tips
Integration with our Google Business Profile
Client testimonial section

This distinction is critical for two reasons. First, it helps the developer prioritize. Second, it makes estimation more honest: the must-haves get a firm estimate, and the nice-to-haves get quoted separately so you can decide based on budget.

Section 3: Your Audience

Who is visiting this website? This informs design decisions, content strategy, and technical choices.

Include:

Who your primary audience is (age range, technical comfort, how they’ll find you)
What devices they use (mostly mobile? mostly desktop?)
What they’re looking for when they visit (information? booking? pricing?)
What action you want them to take

Example:

Our visitors are primarily homeowners aged 30–55 in central Austin. They’re searching on their phones for “landscaping near me” or “lawn care Austin.” They want to see our work, understand our pricing, and request a quote. The main action we want is a contact form submission or phone call.

This tells the developer: mobile-first design, local SEO matters, the CTA should be prominent, and the site speed on mobile is critical.

Section 4: Examples You Like (and Don’t)

Visual references communicate more than words. Share 3–5 websites you admire and explain why.

Helpful:

“I like example.com because the layout feels clean and uncluttered. The photos are large and high-quality. I like how the services are organized into cards. I don’t like how their contact page is buried. I want ours to be easier to find.”

Not helpful:

“I like example.com. Make ours similar.”

The “why” is what matters. Your developer needs to understand what you’re responding to. Is it the layout? The color scheme? The photography style? The overall feeling? Without that context, they’re guessing.

Also share examples you don’t like: “I don’t want our site to feel like competitor.com. It’s too busy, the colors are aggressive, and the text is hard to read.” This is just as useful as positive examples.

Section 5: Content

Content is the single biggest bottleneck in website projects. Developers can build a beautiful site, but it needs words, images, and information to fill it.

Be clear about who’s providing what:

Content	Who provides it?
Written copy (homepage, about, services)	You or a copywriter
Photos of your work / products	You
Team headshots	You
Testimonials / reviews	You (gather from existing customers)
Logo files	You (original high-resolution files)
Brand guidelines (colors, fonts)	You (or the developer creates them)

If you’re expecting the developer to write your copy, say so, and expect it to cost more. Good copy is a separate skill, and brand voice takes time to develop.

Set a content deadline. The most common project delay isn’t development. It’s waiting for the client to provide content. Agree on a date and stick to it. On my own projects, I collect everything at kickoff for exactly this reason.

Section 6: Budget and Timeline

Budget

I know this feels awkward. Many clients don’t want to share a budget because they’re afraid the developer will just charge whatever they say. Here’s why sharing a range helps:

A developer can build a website for almost any budget. But the scope changes dramatically. Sharing your budget range lets the developer propose a realistic plan: “For that budget, here’s what we can include. These nice-to-haves would push it to X.”

Without a budget range, you’ll get one of two things: a quote that’s way more than you expected (and an awkward conversation), or a scope that’s been artificially constrained without you knowing what was cut.

How to share it: “Our budget range is roughly X–Y. We’d like to understand what’s realistic within that range.” If you genuinely don’t have a sense of costs, my template vs custom comparison provides a starting framework.

Timeline

Be honest about deadlines. “We’d like to launch before the holiday season” is useful. “We need it by Friday” for a multi-page site is not realistic.

Typical timelines:

Simple site (5–7 pages, template-based): 2–4 weeks
Custom site (10+ pages, custom design): 6–12 weeks
Complex site (custom features, integrations): 3–6 months

These are working time, not including time spent waiting for content, feedback, or approvals.

Section 7: Ongoing Needs

What happens after launch? This affects the technical choices your developer makes.

Questions to answer:

Will you update the content yourself, or will you need the developer to do it?
Do you need a blog or news section that you’ll publish to regularly?
Will you need ongoing maintenance, security updates, and hosting management?
Are there future features you’re planning (online store, booking system, client portal)?

If you’ll be updating content yourself, the developer needs to build a CMS or choose a platform that supports non-technical editing. If you’re planning to add e-commerce later, the developer should choose a foundation that supports it.

The Brief Template

Here’s a fill-in-the-blank version you can copy and customize:

WEBSITE PROJECT BRIEF

1. ABOUT US
Company name:
What we do:
Our customers:
What makes us different:
Business goals:

2. WEBSITE GOALS
The website should allow visitors to:
- [action 1]
- [action 2]
- [action 3]

Must-have features:
-
-
-

Nice-to-have features:
-
-

3. OUR AUDIENCE
Primary visitors:
Devices they use:
What they're looking for:
Desired action:

4. EXAMPLES
Sites we like (and why):
- [URL], because:
- [URL], because:

Sites we don't like (and why):
- [URL], because:

5. CONTENT
We will provide: [list]
We need help with: [list]
Content delivery deadline:

6. BUDGET & TIMELINE
Budget range:
Desired launch date:
Hard deadline? (yes/no):

7. AFTER LAUNCH
Content updates: [us / developer]
Ongoing maintenance: [yes / no]
Future plans:

What to Leave Out

A good brief focuses on what and why, not how. Leave these to the developer:

Technology choices. Unless you have a specific requirement (like a WordPress site because your team already knows it), let the developer recommend the stack.
Detailed visual design. Describing colors, fonts, and layouts in words is imprecise. Share examples instead and let the developer propose a design.
Technical specifications. “Use a PostgreSQL database with serverless functions.” Unless you’re technical yourself, leave implementation details to the professional.

Your job is to clearly communicate the problem, the audience, and the goals. The developer’s job is to propose the best solution.

The Payoff

A well-written brief takes a few hours. It saves weeks of back-and-forth, prevents misunderstandings, and gives your developer the context to make good decisions on your behalf.

Think of it this way: every question your developer has to ask you during the project is a question the brief could have answered. Every miscommunication that requires rework is a conversation the brief could have prevented.

Your developer is a professional. Give them a clear brief, and they’ll give you a website that actually serves your business.

Ready to start a project? Send me your brief.