Skip to content
Blog

Running Web Projects

The Anatomy of a Great Project Brief (Template Included)

2026-08-24 · 7 min read

Most web projects don't go wrong in the code. They go wrong in the first email.

"We need a website, something modern, how much?" is the message every developer receives weekly. It cannot be quoted. So the developer either pads the price to cover the unknowns, or schedules a call, then another, then a proposal round — and two weeks pass before anyone writes a line of code.

A one-page brief fixes this. Not a 40-page requirements document — one page that answers ten questions. Here's exactly what to write, with a template you can copy.

Why a brief lowers your price

When a developer quotes a vague project, they price the risk, not the work. Every unanswered question becomes a buffer: unclear scope, +20%; unknown content situation, +15%; "we'll decide the pages later", +25%. Vagueness is the most expensive thing you can put in an email.

A clear brief does three things:

  1. Removes the risk buffer. The developer quotes the actual work.
  2. Makes quotes comparable. Three vendors quoting the same brief give you numbers you can actually line up. Three vendors guessing at a vague email give you €900, €4.000 and €12.000 — and you learn nothing.
  3. Shortens the project. In our experience, a project with a clear brief skips at least one discovery call and one proposal revision. That's often a week saved before work even starts.

The 10 questions every brief must answer

1. What does your business do, in two sentences?

Not your mission statement. What you sell, to whom, and where. "We're a family-run physiotherapy clinic with two locations, mostly serving patients aged 40+" tells a developer more than three paragraphs of brand values.

2. What should the website do?

One primary job. "Get visitors to book an appointment." "Sell our 30 products online." "Make us look credible when a prospect Googles us before a meeting." If you list five jobs, rank them — a site optimised for everything is optimised for nothing.

3. Who is the visitor?

Age range, technical comfort, device. "Mostly mobile, arriving from Instagram, deciding in under a minute" produces a very different site than "procurement managers comparing suppliers on desktop."

4. What pages or features do you actually need?

List them. Even a rough list — Home, Services (4), About, Contact with form, blog later — turns a guess into a quote. For features, describe the behaviour, not the technology: "customers pick a time slot and get a confirmation email" is better than "we need a booking module."

5. What exists already?

Current site (URL), domain, logo, brand colours, photos, text. This is the single biggest hidden cost driver. "We have professional photos and final text" versus "we have nothing" can move a project price by 30–50%, because content production is real work someone has to do.

6. What are 2–3 sites you like — and why?

The "why" is the useful part. "I like example.com because the prices are visible without clicking" is actionable. "I like it, it's clean" is not.

7. What is your budget range?

Nobody likes writing this down, but hiding it wastes everyone's time. A range is enough: "€1.000–2.000" or "up to €5.000 if justified." A developer can then tell you honestly what fits — or that it doesn't, before you've spent three calls finding out. For context: simple business sites typically run from a few hundred to a couple thousand euros with freelancers and small studios, and €3.000–6.000+ with city agencies; online stores start around €2.500–3.500 and go up.

8. What is your deadline — and is it real?

"Before our trade fair on 15 October" is a real deadline that shapes decisions. "ASAP" is not a deadline, it's a mood. If there is no hard date, say so — it gives the developer room to sequence work sensibly.

9. Who decides, and who provides content?

One name per role. Projects with three approvers and no content owner are the ones that take four months. If your cousin needs to approve the design, put that in the brief now, not at delivery.

10. What happens after launch?

Who updates the site? Do you want to edit text yourself? Do you expect maintenance, backups, and security updates handled for you (typically €30–300/month in the market)? Answering this up front avoids the classic post-launch surprise.

Good answer vs vague answer

Question Vague (unquotable) Good (quotable)
Purpose "A modern website" "Get 10+ contact form submissions/month from local searches"
Features "Booking or something" "Visitors pick a 30-min slot; we get an email; they get a confirmation"
Content "We'll sort it out" "Text final for 5 pages, need 10 stock photos sourced"
Budget "Cheap but good" "€1.500 max, phased if needed"
Deadline "ASAP" "Live by 1 March for the campaign launch"

The copy-paste template

Paste this into an email or document and fill it in. Twenty minutes of writing, weeks of avoided back-and-forth.

# Project Brief — [Company name]

## 1. About us
What we do, for whom, where: ...
Website (if any): ...

## 2. Primary goal of the site
The one thing the site must achieve: ...
Secondary goals (ranked): ...

## 3. Our visitors
Who they are, what device, how they find us: ...

## 4. Pages & features
Pages: ...
Features (describe behaviour, not tech): ...

## 5. What we already have
Domain: yes/no — Logo: yes/no — Brand guide: yes/no
Text: final / draft / nothing
Photos: professional / phone / nothing

## 6. References
Site 1 + what we like about it: ...
Site 2 + what we like about it: ...

## 7. Budget range
€ ... to € ...

## 8. Timeline
Hard deadline (and why): ...

## 9. People
Final decision-maker: ...
Content provider: ...

## 10. After launch
Who updates the site: ...
Maintenance expected: yes/no

Three honest tips before you send it

  • Don't specify technology unless you must. "It must be WordPress" narrows your options and sometimes raises the price. Specify outcomes; let vendors propose the tool. (Exception: real constraints, like an existing system it must integrate with.)
  • Send the same brief to every vendor. That's the whole point — comparable quotes.
  • Expect questions anyway. A good developer will still ask two or three sharp questions. That's a green flag. A vendor who quotes a vague brief instantly, with no questions, is pricing blind — and one of you will pay for it later.

A brief this clear usually gets you a firm quote within a day or two instead of a week of calls. If you've filled in the template and want a fast, concrete number on it, send it through our project estimator and we'll respond with real figures, not a range of maybes.

Comments (0)

No comments yet — start the conversation.

Sign in to join the conversation. Sign in · Create an account

Related articles

Ready when you are

Tell us what you need. Get a realistic estimate in two minutes.

Get an estimateA fast, personal reply — from the engineer.
feitura

Custom websites and web software, engineered end-to-end by senior hands.

Greater Lisbon (Sintra), Portugal — working worldwide

Our guarantees

  • A personal reply to every inquiry — from the engineer, not a bot
  • Fixed-scope quote before any payment
  • You watch the real build take shape in your portal — no big-reveal surprises
  • You own 100% of the code on final payment

Contact

[email protected]
© 2026 FeituraPrivacyTermsfeito. — made in Portugal