Brief a Web Developer and Get the Site You Pictured

Most unhappy website projects were not badly built. They were badly briefed. The developer delivered exactly what was agreed, and what was agreed was three adjectives and a logo. Six weeks later you are looking at something that works, loads, and leaves you cold, and nobody can say precisely why because nobody wrote down what "right" looked like.

A good brief is not a long document. It is three things: examples with reasons attached, your real content, and a clear statement of the decision you want a visitor to make. Everything else is detail that can be sorted out in the build. Get those three right and you will argue about colours instead of about whether the whole thing missed the point.

What a brief is actually for

A brief is a translation device. You hold a picture in your head of how the business should come across. The developer holds a toolkit. The brief is how the picture gets into the toolkit without being flattened on the way.

The reason "clean, modern, professional" fails is not that it is vague in the abstract — it is that those words mean genuinely different things to different people. Clean to one person means white space and a single column. To another it means dense, tidy, everything visible without scrolling, the way a well-run trading site looks. Both are defensible. If you say "clean" and the developer builds the wrong one, you have both behaved reasonably and you have wasted a month.

So the job of the brief is to remove the places where two reasonable people can read the same words differently. Examples do that. Adjectives do not.

Bring five sites, and say why

Before the first meeting, spend an hour collecting five websites and writing one line against each. Not five sites you like. Five sites you have a specific opinion about.

• Two competitors. Direct ones, in your city if possible. Say what you would steal and what you would never do.
• One site from outside your industry that feels like how you want to come across. A hotel, a bank, a clothing brand — doesn't matter.
• One site you actively dislike, with the reason. "The enquiry form asks for eleven fields" is a reason. "It looks cheap" is not yet one — push until you can name the thing.
• Your own current site, with an honest note on what it does badly. If you are not sure, open it on your phone on mobile data and try to find your own phone number.

The "why" line is the whole value. "I like this one" tells a developer nothing — they cannot tell whether you meant the typography, the photography, the fact that pricing is on the page, or the fact that a human face appears above the fold. "I like that their prices are visible without asking" is an instruction. It survives being passed to a designer who was not in the room.

What we would not bother with

A mood board of abstract imagery — marble textures, sunsets, a colour palette pulled off a design site — is a lovely hour and usually a wasted one. It sets a feeling but gives no guidance on layout, hierarchy or content. Similarly, a paid discovery workshop that ends in a thirty-slide deck and no decisions is something agencies sell happily and we would not buy. Discovery is useful when it ends in a sitemap, a page-by-page content plan and a named decision. If it ends in a deck, you have bought a document, not a direction.

Bring real content, not placeholder

This is the single biggest cause of projects that stall at 80 per cent. The design is approved with dummy text, and then your actual company description turns out to be four hundred words where the design allowed sixty, your product list has nine categories where the menu allowed five, and the "team" section needs eleven photos you do not have.

You do not need finished copy before the first meeting. You need honest raw material:

1. A rough list of pages you think you need, even if it's wrong. Ten lines in a notebook is fine.
2. Your actual product or service list, with the real names and the real number of items. If you sell 340 SKUs, say 340 now, not in week five.
3. Photographs you own. Open the folder and look. Are they of your real premises, staff and products, or are they stock? A site built on stock photography of a Scandinavian office is a site that will never feel like your business.
4. The sentence you say on the phone when someone asks what you do. Write it exactly as you say it. It is almost always better than anything written to sound like a website.
5. Anything with a legal or factual constraint — GST details, licence numbers, disclaimers, delivery areas, return policy. These take up space and are always forgotten.

If you genuinely do not have content and do not want to write it, say so in the first meeting and agree who is producing it and by when. A project where "client to supply content" sits unchallenged in a proposal is a project with a built-in delay.

Name the decision the site should cause

Here is the question that reorganises everything: when the right person finishes reading, what do you want them to do in the next five minutes?

Answer it in one sentence, with a verb. Not "build brand awareness". Something like:

• "Send me a WhatsApp with their drawing attached."
• "Call the showroom and ask whether we have it in their size."
• "Book a thirty-minute consultation on a Tuesday or Wednesday."
• "Add it to the basket and pay, without phoning first."
• "Download the spec sheet and forward it to their technical head."

That one sentence decides more than you would think. It decides whether the homepage needs a price list or a credibility section. It decides whether your enquiry form asks for three fields or ten — a form feeding a sales team that calls back the same afternoon can be short, a form that triggers a detailed quotation may need more. It decides whether the phone number is a link that dials on tap or a line of text in the footer. It decides whether you need a CRM to catch and route enquiries or whether a shared inbox is honestly enough for now.

If different pages should cause different decisions, say that too. A service page and a blog post are not trying to do the same job, and designing them as if they were is how you end up with a blog nobody follows up on.

Be honest about the second audience

Many Indian B2B sites have two readers: the person who will buy, and the person who already decided and is checking you are real. The second one is looking for an address, a landline, a GST number, photos of the actual premises, and names of people. They will not fill a form. Tell your developer if that audience exists, because it changes what goes in the footer and whether you need an about page with substance.

What to decide before the first meeting

Four things are worth settling in your own head, because they change the shape of the quote and they are expensive to change later.

Question	Why it matters
Who updates the site afterwards — you, a staff member, or us?	Decides how much of the site needs to be editable, which affects build time and cost.
Does anything need to connect to something else?	Payment gateway, inventory, accounting software, WhatsApp. Connections are the slowest part of any build.
Who owns the domain and hosting login?	If nobody in the room knows, find out now. Chasing a former vendor for a domain transfer can take weeks.
Is there a hard date?	An exhibition, a product launch, a financial year. Say it out loud; it changes what gets built first.

On scope, one warning. "Unlimited revisions" sounds generous and usually is not. It removes the pressure to decide, and projects where nobody has to decide tend to drift for months. A fixed number of review rounds at named stages — sitemap, homepage design, first build — is better for you, because each round forces a clear yes or no. If you want to understand how a build is typically structured before you walk in, our page on how we approach website development lays out the stages.

Things you genuinely cannot brief

Be fair to yourself about the limits. Some outcomes are not within the developer's control and should not be written into the brief as if they were.

Rankings are the obvious one. A well-built site removes technical obstacles — pages that return proper 200 status codes rather than soft errors, a sensible URL structure, pages that load fast enough to pass Google's Core Web Vitals thresholds, such as Largest Contentful Paint at or under 2.5 seconds. Those are real and checkable. But nobody can tell you where you will rank, and the honest position on search visibility is that the build removes handicaps rather than guarantees positions.

How AI assistants summarise your business is even less settled. The tools that answer questions directly are changing quickly, the signals they use are not fully documented, and anyone claiming a reliable method is ahead of the evidence. It is worth building a site that states facts plainly and consistently, because that cannot hurt, but it should be a hope in your brief, not a requirement. We write about what is and is not knowable in AI visibility.

And conversion rate. You can brief the decision you want caused. You cannot brief how many people will make it, because that depends on your prices, your competition and who is arriving at the page in the first place.

What to do next

Open a document. Write the five sites with one line each. Write the sentence you say on the phone when someone asks what you do. Write the one decision you want a visitor to make in the next five minutes. Add your real page list and a note on who will supply content and photographs.

That is the brief. It will take an hour and it is worth more than any template you can download. Bring it to the meeting, and spend the time arguing about whether it is right rather than guessing what you meant. If you would like a conversation that starts from that document, get in touch and bring it with you.

Questions we get asked