Guide · Planning a website
Website brief template: what to tell developers before asking for a quote
A good brief is short, specific and honest about what you know and do not know. It lets developers understand the task quickly, ask better questions and give estimates you can compare. It is not a technical specification — that comes later, often together with the developer. Below is a template you can copy and fill in; most businesses need one or two pages.
[ 01 ]
In short
In short
- 01
Describe goals and audiences before pages and features.
- 02
List must-have functions separately from nice-to-have ones.
- 03
Name integrations and languages explicitly — they affect cost the most.
- 04
Say who provides content and who approves decisions.
- 05
Give a budget range or at least an order of magnitude; it saves everyone time.
[ 02 ]
Guide
The template
1. About the company
- What you do, for whom, in which markets.
- Current website address, if any, and what is wrong with it.
- Main competitors or companies you compare yourself with.
2. Goals
- What the website should achieve: enquiries, sales, bookings, recruitment, trust, internal efficiency.
- How you will measure success.
3. Audiences
- Who visits and what each audience needs to find or do.
- Which languages each audience uses: Azerbaijani, Russian, English, others.
4. Structure and pages
- Main sections and pages you expect; approximate number of services, products or projects.
- Any content types with special structure: product catalog, project portfolio, team, events.
5. Functions
Must-have:
- forms and what happens with submissions;
- catalog, search, filters;
- online payment, booking, customer accounts;
- blog or news;
- chat or messenger integration.
Nice-to-have: list separately.
6. Integrations
- CRM (which one), 1C or accounting, payment provider, delivery services, analytics, email marketing, messengers.
- Whether these systems have APIs, if you know.
7. Content
- Who writes texts and in which languages; whether translation is needed.
- Photos and video: existing, to be produced, or stock.
- Existing content to migrate from the old site.
8. Design
- Brand materials: logo, colours, fonts, guidelines.
- Examples of sites you like and dislike, with a sentence on why.
9. Technical preferences
- Preferred or required platform, hosting, if any.
- Who will edit the site and how often.
- Requirements for security, accessibility or data storage.
10. Timeline
- Desired launch date and whether it is fixed (for example, tied to an event).
- Your team's availability for reviews.
11. Budget
- A range or an upper limit. Developers can then propose what fits, rather than guessing.
12. Decision-making
- Who is the main contact, who approves, and how many people will give feedback.
13. After launch
- Whether you need support, hosting, updates, content work, marketing.
Tips
- Be honest about uncertainty. "We are not sure whether we need online payment" is useful information.
- Avoid prescribing solutions if you are not sure; describe the problem instead.
- Attach what you have: analytics screenshots, examples, current texts, lists of products.
- Send the same brief to every contractor so proposals are comparable. See comparing web agency proposals.
After the brief
Expect questions. A contractor who asks good questions before quoting is usually one who will deliver what you need. For larger projects, a paid discovery stage — to define scope precisely — is often the best first step.
[ 03 ]
FAQ
Frequently asked questions
Is a brief the same as a technical specification?
No. A brief describes goals and needs in business terms. A technical specification describes exactly how the system should work and is usually written with the developer.
What if we do not know our budget?
Give an order of magnitude or ask for estimates of two or three scope options. Without any range, proposals are harder to compare.
Should the brief mention SEO?
Yes: whether you need search visibility, in which languages, and whether an existing site's traffic must be preserved during a redesign.