What questions to ask in a web project brief?

What's the biggest problem the business has today? Who's the ideal customer? How do leads currently arrive? What's the concrete goal (sell more, organize process, appear on Google)? What's the real budget? What's the required deadline? These 6 cover 90% of the brief.

Brief in writing or via call?

Both. Form first so the client reflects and answers calmly, call afterward to dig deeper and capture what doesn't fit in a form. A 1-hour camera-on call extracts more information than 10 emails.

How to avoid scope changes during the project?

Signed scope document before starting, with a clear list of what's included and what's not. Changes during execution go into a separate spreadsheet and are charged. Client sees transparency, you protect margin.

How long should the briefing phase last?

1 week for small projects, 2 weeks for large ones. Includes initial form, call, reference research, scope document and approval. Well-done discovery saves 2-3 weeks of rework later.

How to brief a web project (a guide for clients)

The brief nobody does right

Most web projects start with a vague conversation. “I want a modern site.” “I need a system for my company.” “Make something like this site here.” The dev interprets it their way, starts building, and halfway through the client says “that’s not what I wanted.”

The rework that follows costs time, money, and patience on both sides. And it’s almost always caused by the same problem: a bad or nonexistent brief.

This post is for you, the person hiring a dev. You don’t need to be technical. You need to answer the right questions before work begins. The clearer the brief, the fewer surprises at delivery.

What the dev needs to know (and you need to answer)

1. What’s the site’s goal

“Having an online presence” isn’t a goal. It’s a consequence. A goal is what you want to happen when someone visits the site.

Concrete examples:

“I want patients to schedule an evaluation via WhatsApp” (lead capture)
“I want to appear on Google when people search [service] in [city]” (local SEO)
“I want clients to place orders without calling the office” (automation)
“I want to show my portfolio to close deals in meetings” (presentation)

Each goal changes the site structure, sections, CTAs, and content strategy. A site for lead capture is different from a site for presentation. Without knowing the goal, the dev builds what they think makes sense, not what solves your problem.

With Family Pilates, the goal was clear: attract new students via organic Google traffic. That defined everything: local SEO as priority, LocalBusiness Schema.org, testimonials section, WhatsApp CTA on every section. If the brief had been “make a nice site,” the result would’ve been different and probably worse.

2. Who’s the audience

Who will access the site? Age, context, level of tech familiarity. This changes language, design, and even the platform.

A 50-year-old construction manager accessing from a phone at a job site is different from a 25-year-old designer accessing from a MacBook at the office. The first needs large buttons, readable text, and fast loading on 3G. The second tolerates more visual complexity.

With Tok Final, the audience is construction managers and builders. Technical language, no fluff, a site that works on bad connections. With Soline, the audience is business owners interested in solar energy. Investment and return language, with concrete savings data.

If you don’t know who the audience is, the dev doesn’t know who they’re building for.

3. What competitors do

Not to copy. To understand what works and what doesn’t in your market. Send 3-5 competitor links and say what you like and dislike about each.

“Dr. Smith’s site is beautiful but has no pricing.” “Clinic X’s site loads fast but the design is dated.” “Competitor Y’s site has a blog with good content.”

This analysis saves hours of conversation. The dev understands the market level, what the audience expects, and what differentiates you.

4. What content you already have

Ready-to-use text? Professional photos? High-resolution logo? Institutional video? What do you already have and what needs to be created?

Content is the part that delays projects most. The dev finishes the layout in 2 weeks and waits 3 weeks for text and photos. If you know you don’t have content ready, agree on this upfront. The dev can help with copy (or recommend someone) and you can schedule a photographer in parallel with development.

In my experience, the ideal is to have at least draft text and raw photos before starting. It doesn’t need to be perfect. It needs to exist. Final copy and image optimization are part of the development process.

5. Visual references

Send examples of sites you like. They don’t need to be from the same industry. It can be “I like the color palette of this site,” “I like the typography of this other one,” “I want this feeling of lightness.” Visual references are much more useful than descriptions like “modern” or “clean,” which mean different things to different people.

3 to 5 links with short comments about what you like in each one is enough. If you have a logo and defined color palette, send those too. If not, the dev can suggest.

6. Budget and timeline

Seems obvious, but many people omit budget out of fear of “paying more than necessary.” The effect is the opposite: without knowing the budget, the dev might propose something that costs 3x what you can pay, and both sides waste time.

It doesn’t need to be an exact number. A range works: “my budget is between R$3 and R$5k” or “I don’t want to spend more than R$8k.” This allows the dev to propose a scope that fits the investment.

For reference on real price ranges, I detailed everything in the post about how much a custom web system costs. Landing pages, simple webapps, complete webapps, SaaS MVPs. Each range with concrete examples.

Timeline matters too. “I need it next month” is different from “no rush.” A tight deadline can increase cost (priority over other projects) or reduce scope (fewer features in the first version).

The brief format

It doesn’t need to be a formal document. It can be an email, a Google Doc, or even organized WhatsApp messages. What matters is that the information is recorded, not just spoken.

Simple structure that works:

1. Goal: what I want the site to do
2. Audience: who will access it
3. Competitors: 3-5 links with comments
4. Available content: what I have ready
5. Visual references: sites I like
6. Budget: investment range
7. Timeline: when it needs to be live
8. Extras: any relevant information

If you fill in these 8 points, the dev has enough material to put together an accurate proposal. Without these points, the proposal is a guess.

What happens with a good brief

With a clear brief, the dev creates a detailed proposal: defined scope, listed sections, estimated timeline, fixed price. You know exactly what you’ll receive, when, and for how much.

In my workflow, the brief becomes an .md specification file. This file contains: site sections, copy for each block, color palette, typography, performance targets, and SEO rules. The client approves the spec before I write a single line of code. Any change after approval follows the rules for scope changes.

The result: less rework, fewer surprises, less “that’s not what I wanted.” The brief isn’t bureaucracy. It’s a 1-hour investment that saves 10 hours of rework.

With GPM2, the brief was done in a 40-minute meeting. Clear goal (capture leads from companies needing tax consulting), defined audience (business owners and accountants), visual references (3 premium consulting sites). With that, I built the complete spec and the site was approved on the first presentation. Zero extra revision rounds.

Common brief mistakes

“Make it like this site.” Copying a competitor’s site doesn’t work for several reasons: you don’t know what works on that site (it might be beautiful and not convert), the audience might be different, and copying design is ethically questionable. Use as reference, not as a model.

Brief by phone with no record. Phone calls are great for alignment, but if nothing is recorded in writing, you and the dev will remember different things. Agree by phone, record in writing.

Infinite scope. “I want a site with a blog, member area, e-commerce, scheduling, live chat, and integration with 5 systems.” That’s not an MVP, that’s a 6-month product. Prioritize. What needs to work on day 1? The rest comes later.

Vague feedback. “I didn’t like it” doesn’t help. “The title is too big, the button color doesn’t match the brand, and the testimonials section needs real photos” helps. The more specific the feedback, the faster the adjustment.

Brief checklist

Site goal defined in one sentence
Target audience described (who, age, access context)
3-5 competitor links with comments
List of available content (text, photos, logo)
3-5 visual reference links with comments
Budget range informed
Delivery timeline agreed
Everything recorded in writing (email, doc, or message)

Filling in this checklist before talking to the dev is the best time investment you can make on the project. The result is a more accurate proposal, faster development, and a delivery that actually solves the problem.