Fazley RabbiA good website brief is a short document, often one or two pages, that tells a developer what your business does, what the website must achieve, who it is for, what it should contain, and the limits they must work within: a budget range, a timeline and who decides. It does not need technical language. It needs specifics. With a clear brief you get proposals you can compare fairly, and a project with far fewer surprises.
What a brief is, and what it is not
A brief is your side of the first conversation, written down. It is not a technical specification, and you do not need to choose a platform or framework; that is the developer's job, and a good one will explain the options. It is also not a wish list of every feature you have seen on other sites. The aim is to describe the problem and the goal clearly enough that someone outside your business can propose a sensible solution.
The sections of a useful brief
About the business
Two or three sentences: what you sell or do, where, and for whom. Mention anything that shapes the site, such as selling mainly through Facebook and WhatsApp, delivering across the country with cash on delivery, or serving buyers abroad.
Goals
What should change once the site is live? More enquiries, online orders, fewer repetitive phone questions, credibility with corporate buyers, a proper place to send ad traffic. Put them in order of importance.
Audience
Who visits and what they need: their language (Bangla, English or both), the devices they use, and what they want to find quickly.
Pages and features
A rough page list (home, services, about, contact, catalogue) and any features: online ordering, payments, appointment booking, Bangla and English versions, a staff-only area. Mark each one "must have" or "nice to have". Essential business website pages can help you decide.
Content
Who will write the text and supply the photos? Is your product data in a spreadsheet? Will content move over from an existing site? Be honest here, because content is where projects most often stall.
Examples
Two or three websites you like and one you dislike, with a sentence on why. "I like how clearly this one explains delivery" is far more useful than "make it look like this".
What you already have
A domain, hosting, business email, a Facebook shop? Who holds those logins? Which other systems should the site connect to, such as accounting software, a courier service or a CRM?
Budget range, timeline and approvals
Give a realistic range rather than "as cheap as possible"; it lets the developer suggest what fits instead of guessing. Website cost factors explains what drives the price. Note any fixed date, such as a product launch or a trade fair, and name the person who approves designs and payments.
A short sample brief
Here is how a brief might read for a hypothetical furniture maker in Jashore:
We make solid-wood furniture to order and sell mainly through our Facebook page, delivering across the country. Customers ask the same questions in messages: designs, wood types, delivery time and how the advance payment works. We want a website that shows our designs with clear details, answers those questions, and sends serious enquiries to WhatsApp. Visitors are mostly families on phones, reading in Bangla. Must have: a catalogue with categories, a questions page, a WhatsApp button, Bangla first with English later. Nice to have: online advance payment. We have product photos but no written descriptions yet. We own the domain, but the login is with a former employee. Approvals: the owner. We would like to launch before the wedding season.
In a few lines it covers the business, goals, audience, features with priorities, content status, existing set-up, the decision-maker and timing. A business moving from Facebook-only selling to its own site has some extra decisions to make; moving from Facebook selling to your own website walks through them.
Mistakes that make a brief hard to work from
- Only adjectives: "modern, attractive, user-friendly" describes every website ever requested.
- Pointing at a competitor's site without saying what you actually like about it.
- No priorities: twenty features with equal weight make an accurate quote impossible.
- Hiding the budget: you receive proposals that are far apart and hard to compare.
- Leaving out constraints: a deadline, a required integration or an existing system mentioned only after work has started.
- Too many authors: a brief written by committee, full of contradictions nobody resolved.
Before you send it
- Could someone outside your business understand what you do from the first paragraph?
- Are the goals in order of importance?
- Is every feature marked must have or nice to have?
- Have you said who provides content, and by when?
- Is there one named decision-maker?
Once your brief is ready, how a website project runs explains what happens next. If you would like me to read your brief and suggest an approach, see my web development service.