Answer in brief
A good brief fixes scope rather than taste. This is what belongs in one: the five answers needed before any quote, why the page list drives the estimate, who owns the copy and the translations, and how the document maps onto packages with named prices.
What a brief is for, and what it is not
A brief exists to fix scope. It is the document that turns a conversation about a website into a list a developer can price, schedule and later be measured against. Everything a brief does well, it does by making one of those three things less negotiable.
That is a different job from describing taste. A reference to a site you admire tells a developer about the visual register you want; it does not tell them how many pages exist, who writes the text, or which system the order form has to reach. Taste belongs in a brief, but it cannot carry it.
The practical test is simple. Hand the document to someone who has never met you, and ask them to name the number of pages, the launch date and the person responsible for the copy. If they cannot, the brief is still a wish list.
What follows is the shape of a brief that survives that test, section by section, with the parts owners usually leave out marked as they come. It ends with how the finished document maps onto packages that already carry fixed prices and timelines.
The one-page version: five things before anyone quotes
Before any detail, five answers decide whether a quote is even possible: what the site is for, how many pages it has, who supplies the content, what has to connect to it, and when it must be live. A developer who has those five can put a number on the work.
Everything else in a brief is elaboration of those five. If you are short of time, write one page containing only them and send it. A one-page brief that answers all five gets a firmer quote than a twenty-page document that answers three.
The order matters as well. Purpose selects the page list, the page list selects the content workload, and the content workload usually sets the real timeline. Starting from the design instead reverses that chain and produces an estimate that moves every week.
Treat the one-pager as a draft you will keep. The longer brief is not a replacement for it; it is the same five answers with the detail attached, and the one-pager stays useful as the summary everyone can hold in their head.
Purpose: name the single action the site must produce
Write down the one action you want a visitor to take. A booking, a call, a filled form, a completed order, a downloaded file. A site can support several, but a brief that names one gives every later decision a tiebreaker.
This is the sentence that resolves arguments about layout. When two people disagree about whether the price belongs above or below the description, the named action decides it, and the discussion takes a minute instead of a week.
It also tells you what to measure. If the action is a filled form, then form submissions are the number that matters, and traffic is context rather than the result. Naming it in the brief means the analytics setup has something concrete to record.
Write it in plain language and put it at the top. "A visitor should be able to see prices and send a request without calling us" is a usable purpose. "Increase brand awareness" is not, because nothing in a build follows from it.
The page list is the spine of every estimate
List the pages. Home, services, about, contact, and then the ones specific to you — a catalogue, a booking flow, a portfolio, a set of legal pages. Count them, and mark which ones repeat a template and which are one of a kind.
The distinction between a template and a unique page is where estimates are won or lost. Forty catalogue entries on one template is a smaller job than four pages that each need their own layout, and only the page list makes that visible.
Add what each page must contain, in a line or two. Not the wording — the blocks. "Service page: description, price, what is included, what is not, request form." That line is enough for a developer to see the work and enough for you to notice a missing block.
Mark the pages you can launch without. A brief that separates the launch set from the later set gives you a lever you will want: when the date is at risk, the second list is what moves, and nothing needs renegotiating.
Content: who writes it, who translates it, when it arrives
Content is the part of a website project most likely to slip, and the part a brief most often leaves blank. Write down who produces the text for each page, who supplies the photographs, and the date each is due.
Name real people, not departments. "Marketing will send the copy" has no owner; "Anna sends the service descriptions by the 12th" does. The point is not bureaucracy, it is that a missing owner is invisible until the week you need the text.
Say explicitly whether translations are needed and who produces them. VITON13 does not write the client's content or translations — that sits with you, and pretending otherwise at the brief stage is what turns a five-day build into a five-week wait.
If the content does not exist yet, say so and give a date. A developer can build against placeholder text and swap it later, but only if the plan says that is what is happening. Discovering it at handover is a different and worse conversation.
Design: what already exists and what has to be made
Separate what you have from what you need. A logo, a colour palette, a typeface licence, photographs, a brand book — list what exists and where the files are. Everything not on that list has to be produced, and production takes time.
If you have a brand book, say which parts are binding. Some are strict about colour and typography and relaxed about layout; some are the reverse. A developer who knows which rules cannot be bent stops guessing and stops asking.
Two or three reference sites are useful here, with a sentence on what you want from each. "This one for how the price is presented" is worth more than a bare link, because it separates the part you admire from the parts you do not.
Say what must not happen as well. A colour that belongs to a competitor, a layout your previous site used, a photographic style that is wrong for your market. Constraints stated early are cheaper than corrections made late.
Functions: run every feature through one sentence
For each function you want, write one sentence: who does what, and what happens next. "A visitor picks a date and a time, submits the form, and the request appears in our email and in the CRM." That sentence is the specification.
The sentence test filters out features that sound simple and are not. "Online booking" hides the question of whether the calendar has to know about existing appointments; the sentence version surfaces it before anyone quotes on it.
Sort the list into what launch requires and what can follow. Almost every project has features that feel essential in a meeting and turn out to be comfortably second-phase once the launch date is real. Deciding that in the brief is cheaper than deciding it under pressure.
Be specific about native mobile applications if you are imagining one. A responsive website and an app in a store are separate products with separate work; VITON13's development packages cover the web build, and native mobile apps are named as not included.
Integrations: name the systems and who holds the accounts
List every outside system the site must reach: a CRM, a payment provider, an analytics platform, an email tool, a booking system, a delivery service. Name the product, not the category, because two CRMs with the same job can differ by a week of work.
For each one, say who holds the account and who can grant access. An integration cannot be built against a system nobody can log in to, and waiting for a password is one of the quieter ways a timeline slips.
Say what has to move in each direction. A form sending a lead into a CRM is one job; a catalogue reading live stock out of an accounting system and writing orders back is another. The direction of the data is most of the estimate.
Payment deserves its own line. Which provider, which country, which entity is signing the contract, and who is responsible for the licensing. VITON13's Product Build package names payment licensing as outside its scope, so that responsibility should be settled in the brief.
Constraints: date, budget band, and what cannot change
State the date and say what it is tied to. A trade show, a season, a campaign, a lease. A developer who knows the date is immovable plans differently from one who thinks it is a preference, and the difference shows in what gets proposed.
Give a budget band rather than a single figure or nothing at all. A band lets a supplier tell you honestly which of your requirements fits inside it, which is a more useful answer than a quote built to a number you never wanted to spend.
List the technology you must keep. An existing CMS, a hosting contract with time left, a domain arrangement, an accounting system that cannot be replaced this year. Constraints of this kind are neutral facts, and they change the estimate whether or not you mention them.
Add the legal requirements you already know about: a privacy notice, cookie handling, an accessibility standard your sector expects. The W3C's WCAG 2.2 quick reference is the practical checklist for the last of those and is worth naming rather than implying.
Acceptance: write down how you will decide it is finished
A brief that describes the work but not the finish line leaves the end of the project unstated. Write the acceptance conditions while you are calm: what you will open, what you will click, and what has to be true before you sign.
Keep them concrete. Every page loads on a phone and on a desktop; the form arrives in the inbox and in the CRM; the price shown matches the price list; the site is reachable at the right address over HTTPS. Each is a yes or a no.
Include the measurable ones you actually care about. Speed is a fair example, because MDN's performance documentation gives a shared vocabulary for it, and "the home page is fast" is not a condition anyone can pass or fail.
Name who signs. One person, with a stated period to run the checks. An acceptance process with three reviewers and no deadline is the mechanism by which a finished project stays open for another month.
What a brief should not contain
It should not contain implementation choices you do not have a reason for. Naming a framework because you read about it constrains the build without improving it. State the requirement — a page anyone in the office can edit — and let the supplier answer it.
It should not contain guessed numbers. An invented traffic figure or a speculative conversion target sets an expectation the work will be measured against, and the measurement will not be fair to anyone.
It should not contain requirements nobody owns. Every line that says the site "should" do something needs a person attached, or it will survive every review and be discovered missing at acceptance.
And it should not be long for its own sake. The document exists to be read by people who are pricing and building. Six clear pages beat thirty that bury the page list in the middle of a strategy narrative.
How the finished brief maps onto fixed packages
A brief is worth writing partly because it lets you compare offers on the same footing. VITON13's development service prices five packages, and once your page list and content plan exist, the brief usually selects one of them on its own.
Site Fix Pack is $70 and runs 1-2 working days for up to five agreed fixes, with a mobile and desktop check and a before/after list at handover; it carries one round of revisions and does not cover new pages, redesign or migrations. Launch Site is $380 over 3-5 working days for a responsive build, core CMS or data wiring and deployment setup, with two rounds of revisions before launch and content and translations supplied by you.
Product Build is $880 over 2-3 weeks and covers feature delivery, state and route logic, testing and hardening, with two rounds of revisions per delivered feature; native mobile apps and payment licensing sit outside it. Launch Site Express is $520 and delivers the Launch Site scope in a priority queue over 2 working days with daily builds, a launch checklist and a handover call, one round of revisions after the first full build, and content, photography and ongoing support excluded.
Ongoing Dev Support is $290 per month on a monthly cycle with 30 days notice to stop, covering priority updates, a weekly release rhythm and technical maintenance; the volume is agreed at the start of each cycle, and a new build or redesign is scoped separately. Read the terms of the package you are actually choosing — they differ from each other on purpose.
Practical checklist
- Write the one-page version with the five answers and send it before the long document.
- List every page and mark each one as a template repeat or a unique layout.
- Name a person and a date for copy, photography and translations.
- Put each requested function through the sentence test: who does what, and what happens next.
- Name every external system by product and say who holds its account.
- Write the acceptance conditions and name the single person who signs.
Questions and answers
Do I need a brief if the site is small?
Yes, but a short one. For a small site, a single page carrying five answers is enough: what the site is for, how many pages it has, who supplies the content, what it must connect to, and when it goes live. That is what turns a range into a firm quote.
What does development cost, and how does the brief affect it?
VITON13 prices five packages: Site Fix Pack at $70 over 1-2 working days for up to five agreed fixes, Launch Site at $380 over 3-5 working days, Launch Site Express at $520 over 2 working days, Product Build at $880 over 2-3 weeks, and Ongoing Dev Support at $290 per month. The brief does not change a package price; it shows which package the work belongs in.
Who writes the text — the client or the developer?
Content and translations stay with the client: VITON13 does not write or translate them. The brief therefore needs a named person and a date for the copy on each page, or the schedule ends up set by how long the material takes to arrive rather than by the build.
Should the brief name a specific framework?
Only if you have a reason — an existing system you must keep, or a team that will maintain the site afterwards. Without one, state the requirement instead, such as a page anyone in the office can edit, and let the supplier answer it.
What if the content does not exist yet?
Say so in the brief and give a date. A build can run on placeholder text and swap it later, but that has to be the plan rather than a discovery at handover. Mark which pages can be held back from the first day as well.