Before building a website: the brief that prevents delays and second-guessing

A web project almost always slips for the same reason, and it isn't technical: there's a decision that belongs to the company, no one makes it, and the work stalls right there. The brief exists to make those decisions when changing them costs a meeting, instead of two weeks of rework. It isn't a document for the vendor: it's how the company agrees with itself before the countdown starts.

You don't need everything ready. You need to know what's missing, who produces it, and by when. The difference between a project that moves forward with declared gaps and one that gets stuck on a gap nobody saw coming lies almost entirely here.

The four decisions that can't be delegated

These belong to the company, not to the website. No vendor can make them on your behalf, and as long as they stay open, every choice that follows — structure, copy, design — remains provisional.

1. The goal. What should happen because of the website: receiving quote requests, getting applications in, reducing calls that always ask the same thing, giving the sales team a place to send customers. “Being more modern” isn't a goal, because it doesn't let you choose between two different solutions.
2. The audience. Who needs to recognize themselves in the first lines. A company selling to both individuals and businesses has two readers with different questions, and has to decide whether to serve them in the same place or on two separate paths.
3. The offer. What you sell and with what boundaries: what you do and what you don't, where you work, what sets your work apart from the nearest competitor's. This is the part companies take for granted, and the website can't invent it.
4. The desired action. What someone convinced should do: write in, call, request a site visit, download a spec sheet, book something. One main action per page; the others stay available, but don't compete with it.

The materials: not “do we have them,” but “what state are they in”

The useful question isn't whether the material exists, but whether it's usable as it is. It's worth taking inventory by category and marking each one with a single word: ready, needs revision, needs to be produced.

• Copy. Sales presentations and catalogs almost always contain the substance, but written for a reader who already has you in front of them. They need to be rewritten for someone who doesn't know you, and someone has to be assigned to do it.
• Images. You need photos of products, finished jobs, locations, and people, with permission to use them. Stock images fill the page, but they don't prove anything.
• Technical documents. Spec sheets, certifications, price lists, terms of sale: decide which are public, which are handed over only on request, and who keeps them up to date.
• Access credentials. Domain, name management, email, analytics, business profiles, any licenses. This is the only item on the list that can't be produced quickly if it's missing.

Who decides, and who gathers the input

These are two distinct roles, and it's best if they're two different people. The person gathering input talks to the departments, pulls the feedback together, and delivers it as a single list. The person deciding chooses, even when opinions conflict, and their choice closes the discussion.

The problem isn't having many opinions: it's having them arrive separately, at different times, and often incompatible with each other. Three messages asking for three opposite things on the same page don't produce three changes: they produce a request for clarification and a lost week.

• A single channel for feedback, not parallel conversations.
• A set time to collect it, not a continuous stream.
• One person who, in case of disagreement, decides and takes responsibility for it.
• A rule on who needs to be consulted before launch: usually whoever handles customer responses, whoever manages contractual documents, and whoever is responsible for data handling.

Requests that arrive later, and what they push back

A new request halfway through the work isn't a problem in itself. It becomes one when it comes in without anyone saying what it involves. It's worth setting the rule up front: every addition is assessed on three things, and the assessment comes before starting it.

1. What depends on it. A private area isn't just one more page: it changes how people log into the website, what data gets stored, and who responds when someone loses their password.
2. What it pushes back in time. If the work proceeds in phases, an addition only fits into the current phase if something else comes out; otherwise the date moves.
3. What it involves after launch. Some additions create ongoing work: a catalog has to be updated, a blog has to be written, an application form has to be read by someone.

A completed brief: a services company

The example below is illustrative and involves a company that does system maintenance for other businesses. It's meant to show the right level of detail: neither a generic line nor a forty-page document.

What makes this brief useful isn't its length: it's that every line rules something out. “We don't do new residential installations” removes three unnecessary pages and makes clear who the website is speaking to.

What this guide doesn't cover

This guide takes you as far as having a manageable project: decisions made, materials inventoried, roles assigned. Comparing different cost proposals — why two quotes for the same website land at very different figures and what they actually include — is a separate matter, covered on its own. The checks to run before going live also have a dedicated guide.