Website Project Brief: How to Write One That Prices Right

Why a Vague Brief Quietly Eats Your Budget

Straight answer: a studio can't price your intention, only your document. Everything the document leaves out, both sides fill in silently and differently — and the two pictures finally meet at the demo, when changing course is expensive.

Take a sentence that sounds perfectly clear: we need a company website, about ten pages, with an enquiry form. There are at least four forks hiding in there, and each one costs money:

• The enquiry form — is it an email to an inbox, or does it create a deal in your CRM and send the customer an auto-reply?
• Ten pages — ten unique screens, each designed and built separately, or one template filled in ten times?
• Content — are you handing over finished copy and photography, or does someone have to write and shoot it?
• Languages — one, or three, and who translates?

The gap between the cheap reading and the expensive reading is a multiple, not a rounding error — and both are honest, the answer simply wasn't in the text.

Then comes the schedule. Ambiguity arrives in slices, each dressed as one small thing — a filter here, a calculator there, a quote form on the services page. Each sounds like half an hour; together they rewrite half the project, and launch slips by months. A good requirements document isn't bureaucracy; it's a way to disagree early, while disagreeing is still free. Skip it and the client pays for rework, while the studio eats the cost or argues and loses the relationship.

Brief, Specification, Scope of Work — and Who Writes Them

The brief is an intake document — one or two pages the client fills in: who you are, what you sell, to whom, why you need a site, what you like and hate about competitors, budget, deadline. It describes the problem, not the solution, so it can't be priced accurately — only gauged for order of magnitude.

The technical specification describes what will be built: page list, structure of each page, functionality, scenarios, integrations, admin requirements, acceptance criteria. It's written after the problem is understood, and it becomes an appendix to the contract. The scope of work is the boundary — what's in and what's out. One line saying product-card content is populated by the client is worth more than a page of elegant prose.

Who should write the spec

Short answer: the client writes the brief, the studio writes the spec. You're the expert on your business — margins, seasonality, the objections your salespeople hear. The studio is expert in what will break in month three: which solutions exist and what each costs. Left to write it alone, a client invents solutions where they have no experience, and the result either specifies things that don't work that way or demands everything at once.

So the pattern is: the client fills in a brief; the studio runs discovery — a few sessions of uncomfortable questions, mapping the real business process — then writes the spec, and the client reads it, argues, and signs off. Discovery and spec-writing are real work: a studio that offers a detailed spec for free will produce a formal one, just enough to get a signature. To tell the teams that genuinely dig from the ones that reuse templates, we covered the signals in our guide on choosing a web studio.

The Opening: Business Goal, Audience, Competitors

The first section of any decent spec answers why, not what. Skip it and no later decision can be made: every argument about whether a block is needed comes down to a criterion, and the criterion comes from the goal.

The business goal

State it in business terms, not website terms. "A beautiful, modern site" is an opinion. A goal sounds more like: get installation enquiries from homeowners — right now everything comes by phone and half of it gets lost, or move wholesale customers to self-service. The first makes the form, trust, and speed matter; the second, an account area and one-click reordering. The same budget, different places.

The audience

Describe behaviour, not demographics. "Men, 25 to 45" tells a developer nothing. This does:

• Who decides and who pays — frequently different people.
• How they arrive: searching a problem, following a recommendation, clicking an ad.
• What they verify before they'll commit: price, lead time, licensing, reviews, coverage area.
• What device they're on. A phone on a job site with poor signal changes page-weight requirements.

Competitors

Give three to five links, each with one sentence: what's good here and what's bad. Not "nice design," but "their price is visible immediately without a form — I want that." This one habit saves weeks of email, because it converts taste into requirements. And write honestly how you differ from those competitors: if there's no difference, that's not a website problem, and no amount of front-end will fix it.

Page List and Structure: Where the Estimate Lives

This is where most of the estimate comes from. The rule is simple: you count unique templates, not pages. A catalogue with a thousand products is one product-card template, and an eight-page site designed page by page costs more than thirty pages on three templates. So write the list in two passes: name every page, then mark which are templated and which are one-offs.

How to describe a page

For every unique page, list the blocks top to bottom with the purpose of each. For a service page:

1. Hero: headline, one-line description, button requesting a quote.
2. What's included — bulleted list, five to eight items.
3. How the work runs — three to six steps.
4. Pricing: tier table or a single "from" line; decide at discovery.
5. Related work — three cards, pulled automatically from the portfolio by service tag.
6. FAQ — editable from the admin. Enquiry form.

Notice the two phrases doing the heavy lifting: "pulled automatically by tag" and "editable from the admin." Those aren't decoration, they're hours: a block an editor fills by hand and a block that assembles itself from data are different jobs at different prices.

Navigation and links between pages

Describe the main menu and the footer in full, and how pages connect: services lead to case studies, case studies back to the service and the form, articles to services. A useful test is to walk your future site as a stranger — someone landed on an article, what do they see next and where do they go? If you can't answer, that page isn't finished. You can see how that plays out in our recent work. And don't write "the site must be responsive" — that's table stakes; write where mobile behaves differently: the pricing table becomes stacked cards, the filter opens full-screen. Those spots burn time when they surface late.

Describing Functionality Without Ambiguity

The classic spec mistake is describing features with adjectives — a convenient filter, a smart search, a fast checkout. Those aren't requirements, they're wishes: you can't verify them, you can't price them, and you can argue about them forever — convenient according to whom?

The alternative is scenarios: who does what and what they get. Compare. Weak: "Customer account with order history." Strong:

• The customer signs in with email and password; password reset works via an emailed link.
• The customer sees their orders: number, date, total, status, and a "reorder" button.
• There are five statuses — new, in progress, shipped, delivered, cancelled — set by a manager in the admin.
• "Reorder" puts the items back in the cart; anything out of stock is skipped and the customer is told which.
• The customer downloads a PDF invoice but can't edit the registered company name — only a manager can.

The second version can be priced in hours without a single call; the first only guessed at, off target.

Write down the edge cases

The cost is rarely the happy path — it's everything around it, where half the budget hides:

• What happens with no data: empty cart, search with no results, a category with nothing in it.
• What happens on failure: payment declined, file too large, email already registered.
• What the user sees if the connection drops mid-payment, and who can do what — editors and administrators need different permissions.

And mark every item: required for launch, nice to have, or phase two. This is the single best budget tool that exists: when the estimate comes back higher than you hoped, you'll cut deliberately instead of hacking at whatever is nearest.

Content, Integrations, Languages: Who Provides What, and When

More projects die here than in any line of code. The site is finished and the launch doesn't happen — because the copy never arrived, or the photos are phone snaps taken in a dim warehouse.

Content

The spec has to say plainly who owns each content type and by when it exists:

• Page copy. Written by you, by the studio's copywriter, or drafted by you and edited by us? Three prices.
• Photography. Your archive, a shoot, or stock? If a shoot — who arranges and pays for it.
• Catalogue. Who fills in the cards, where descriptions come from, what format the export arrives in.
• Legal pages. Privacy policy, terms, company details — the client's territory, but the studio should remind you.

And one more line: what happens if the content isn't ready on time. The sane answer is to launch with placeholders on an agreed list of pages, not to hold a finished site in a drawer for months.

Integrations

Describe each one the same way: which system, what moves where, at what moment, and what happens when it fails. "Integrate with CRM" is meaningless — it covers both two hours of work and two weeks. Run through the usual list — CRM, payment gateway, shipping, warehouse software, email marketing, messengers, fiscal receipts, analytics — and for each answer three questions: does it have an API, is there documentation, who holds the credentials. Missing credentials are a risk, and it belongs in the spec rather than surfacing a week before launch.

Languages

Multilingual isn't a switcher in the header. It's a separate data model, separate URLs, separate meta tags, separate editorial work, and a rule for what happens when a page has no translation. Decide up front: which languages at launch, which later, who translates. Retrofitting a second language into a project that never expected one costs more than planning for it on day one.

Design References and the "Make It Like X" Trap

References are necessary: without them a designer is guessing at your taste, and taste can't be guessed over email. But how you supply them matters.

The "make it like X" trap looks harmless and gets expensive. Copying someone else's site won't work for your business — different product, audience, price point — but the deeper issue is that you see a website from the outside while the cost sits on the inside: behind that smooth animation may be three months of work, behind the lively catalogue a warehouse integration, behind "just nice photos" a studio shoot you don't have.

Hence the rule: a reference without a comment is useless. Every link needs a sentence saying what you're actually taking from it:

• "I like how the price is right there, no request form."
• "I like the sense of space — lots of air, little text per screen."
• "I like the structure of the product card, not the colours."
• "I strongly dislike the hero carousel."

Anti-references work just as well: "not like this, too corporate" narrows the search faster than five examples of what you like.

What else to pin down

Whether a brand book exists and how binding it is; tone — formal or conversational; and above all, who approves the design. Projects stall on approvals far more often than on technology, when a mockup goes round to a third deputy director and returns with notes contradicting the first. Put a name in the spec — whose "yes" is final — and agree on a number of rounds. Two or three is normal; unlimited isn't a project, it's a hobby.

Technical Constraints, SEO, and Living in the Admin

This is the section clients skip with "you know best." The studio does know best about solutions — but only you know the constraints you're starting from.

Technical constraints

• Hosting and domain. Where things live now, who holds the credentials, whether rules govern where data may sit.
• The existing system. If a site already exists — what migrates, what gets dropped, what keeps running alongside.
• Internal policy. Security review, password rules, restrictions on third-party services.
• Code ownership and personal data. Who owns the result, what you collect, how it's deleted on request.

SEO

State search requirements as mechanics, not promises. No studio can guarantee rankings, but any studio must deliver the foundation:

• Editable title, description and headings on every page type — from the admin, without a developer.
• Readable addresses, a coherent URL scheme, and redirect mapping on migration.
• Structured data, a sitemap, correct canonicals, and with several languages, proper language attributes.
• Speed stated as specific metrics on a specific device, not as "fast."

The admin and day-to-day editing

The most underrated section in any spec. Answer one question: what will you change yourself, and how often? The answer drives the architecture. Change a phone number once a year and you barely need an admin; assemble new landing pages every week and you need a block builder — a different system and budget. Describe the roles and what happens when an editor makes a mistake: drafts, preview, rollback. And be honest about the skill of the people who'll use it — an interface built for a developer paralyses an ordinary editor.

Acceptance Criteria, Timeline, and a Budget Range

These three close the spec and turn it from a description of a dream into a working document.

Acceptance criteria

An acceptance criterion is a verifiable statement. Not "the site works correctly," but a list of what will be checked:

• Every page on the list opens; no link leads to an error.
• The enquiry form submits, the email arrives, and the lead appears in the CRM.
• The site renders correctly in current browsers and on a phone.
• Speed metrics on the home page and a product card fall within the agreed threshold.
• A test-card payment goes through, an order is created, and the confirmation email is sent.

That list protects both sides: the client knows exactly what to check, and the studio knows where the finish line is instead of facing an acceptance phase that never ends because something feels off.

Timeline

Calendar dates in a spec are usually harmful — stale by week two. Describe the schedule in stages: mockups after structure sign-off, development after mockups, population after content. The operative word is dependency. Deadlines run both ways: if content arrives three weeks late, launch moves — that's arithmetic, not punishment. Write in plainly which deadlines belong to the client: approving mockups, delivering content, granting access.

The budget range

Clients hide the budget, fearing the estimate will be tailored to the number. The result is backwards. A budget isn't a price — it's a constraint on the problem: withhold it and you'll get either a proposal you can't afford or one trimmed past recognition. A range is enough: "we're thinking in this region and we'll discuss more if it's justified." What follows is an engineering conversation about what fits the frame and what moves to phase two. For how a price is actually assembled, and why two sites that look identical cost differently, see our breakdown of what a website costs in 2026.

What Not to Put in a Brief

Bad specs aren't only short ones — an eighty-page monster is also a symptom. Here's what to cut without hesitation.

Evaluative adjectives. Modern, convenient, intuitive, high-converting. None can be verified. Make it checkable instead: rather than "a convenient catalogue," write "a visitor reaches the right product in no more than three actions."

Prescribed technical solutions, if you're not technical. A line saying "build it on this stack," with no reason, ties hands and raises the price. State the constraint instead: "our sysadmin can only support this stack," or "it has to run on our server." The studio will honour the reason and pick the method.

Everything, just in case. "The system should also allow for future expansion of functionality" means nothing, but a conscientious studio will price a buffer against the unknown. You're paying for fog.

Copy-paste from someone else's spec. It's painfully visible when a clinic's spec suddenly grows a shopping cart and delivery options: now nobody knows which requirements are real. Design in prose and legal machinery are out too — one is the mockup's job, the other the contract's.

And what's almost always missing

The flip side: some things get left out of nine specs in ten and don't look important until they fire.

• What happens after launch: who updates the site, who fixes it, who answers at midnight on a Saturday.
• Backups: how often, where they live, who verifies they actually restore.
• Handover: credentials, documentation, an editor's guide, source files, and training for your people.
• What counts as a warranty fix versus a new task.

How the Brief Becomes an Estimate — and Handling Changes

An estimate isn't a number pulled from experience — it's arithmetic performed on a document.

How pricing actually works

The studio breaks the spec into elements and prices each in hours: every unique template, every templated page, every feature, every integration, the admin, testing, launch. On top sit the things absent from the page list but always present — management, communication, revisions, acceptance. From which follows the important part: an estimate is only as accurate as the spec. From a brief you can quote a range, and it will be wide because it's honest. When a contractor reads one paragraph and names an exact price, that's a number from the ceiling — and by the end the ceiling is yours or theirs.

Only compare estimates written against the same spec; otherwise you're comparing different projects. The cheap proposal almost always describes less — no testing, no content population, no integration — and a line reading "website development — total" can't be checked, while an itemised estimate proves the contractor read the spec. Our service scopes are laid out on exactly this logic: structure first, then functionality, then acceptance.

Changes after sign-off

Changes will happen — businesses move, and a demo always reveals things a document couldn't. The question isn't how to prevent them but how to process them:

1. The change is written down — as a line item, not a remark on a call.
2. The studio prices it: how many hours, what moves in the schedule, what it touches.
3. The client decides: do it now, in phase two, or drop it, and the decision is recorded as an appendix.

There's a rule worth memorising: a fix is when the build doesn't match the spec; a change is when the spec didn't match the need. The studio fixes the first for free and prices the second. The line is drawn by a document rather than by mood. And if a feature goes in, either something required moves to phase two or money is added. There is no third option.

Checklist: Your Brief Is Ready If It Has

Run down the list. If more than three items are blank, the document isn't ready to be priced — and any estimate against it is fiction.

1. A business goal in business terms, not website terms.
2. The audience as behaviour: who decides, how they arrive, what they verify, what device they use.
3. Competitors: three to five links, each with a note on what to take and what to avoid.
4. A page list split into unique screens and templated ones.
5. Structure of each unique page: blocks top to bottom and the purpose of each.
6. Features as scenarios: who does what and gets what. Plus edge cases and failures.
7. Priorities: required for launch / nice to have / phase two.
8. Content: who writes copy, who supplies photos, by when, and what happens if it's late.
9. Integrations by name: what moves where, when, what on failure, who has credentials.
10. Languages: how many at launch, who translates, what happens with no translation.
11. Design: annotated references, brand book, who approves, how many rounds.
12. Technical constraints: hosting, access, code ownership, personal data.
13. SEO: editable meta, URL scheme, redirects on migration, a speed threshold.
14. The admin: what you edit yourself and how often, roles, drafts, rollback, training.
15. Acceptance criteria: a verifiable list, not "works correctly."
16. A staged timeline with dependencies, and a budget range.
17. After launch: support, backups, handover of credentials, the warranty boundary.

Before a project starts, don't try to fill the whole list alone in one evening. Fill in what you genuinely know: the goal, the audience, competitors, constraints, the budget range. The rest — pages, features, integrations, acceptance — assembles at discovery, alongside a studio.

A good spec is like a technical drawing: a boring document without which the house gets built by eye. An hour spent on wording before the start saves a day of rework in the middle. If you'd like the spec written with you and priced honestly against it, get in touch — we start with a brief and a conversation, and the document tends to write itself from there.

FAQ