Your website brief is ready when a developer can start building on day one without asking a dozen blocking questions. Concretely, that means six things are settled before the contract is signed: the sitemap, the copy, the brand files, the CMS decision, the integrations, and the timeline.
There was a florist in a town I'm fairly sure doesn't appear on any map who sent me a one-line brief: "make it look nice and modern." We spent 11 days emailing before a single pixel moved. This post is the checklist I wish more clients had before they hired anyone. It's written for small business owners and founders, and it works whether you hire me, another studio, or a freelancer off a directory.
What is a website brief, and why does readiness matter?
A website brief is the document that tells a developer what to build, who it's for, and what "done" looks like. Readiness matters because unanswered questions become billable delays.
Most projects that run over budget don't run over because the code was hard. They run over because the client answered questions slowly. A developer waiting on your logo files or your final headline is not building. On a typical 5 to 8 week small business site, I've watched a shaky brief add 2 to 3 weeks of dead time. If you're paying a day rate of anywhere from $400 to $800, that gap is $4,000 to $12,000 of nothing happening. On a fixed price it's less costly but just as frustrating, because the launch keeps sliding.
The single biggest predictor of a smooth build is whether the client has written their own copy before design starts. Everything else can be worked around. Missing copy stalls the whole thing.
What should a ready website brief include?
A ready brief covers six things: a sitemap, the actual copy, brand assets, a CMS preference, a list of integrations, and a realistic timeline with a hard deadline if you have one.
Here's the short version you can score yourself against.
| Item | Ready looks like | Not ready looks like |
|---|---|---|
| Sitemap | A named list of pages | "The usual pages" |
| Copy | Written text per page, owned by you | "You'll write it, right?" |
| Brand assets | Logo in SVG or high-res PNG, hex colours, fonts | A logo screenshotted from Instagram |
| CMS | A preference or a clear "you decide" | No idea it's even a choice |
| Integrations | A list: booking, payments, email, CRM | "It should just connect to stuff" |
| Timeline | A target date and why | "As soon as possible" |
If you can fill the middle column for all 6, you're ready. If 3 or more land in the right column, you have homework before you hire anyone.
Do you need a full sitemap before you start?
Yes. You need at least the top-level page list, because the sitemap decides the navigation, the scope, and the price.
A sitemap is the list of pages your site will have and how they nest. Home, About, Services, Contact is a 4-page sitemap. So is a 40-page structure with a blog, a resource library, and 8 service pages. The developer prices and plans against this. If you add a "Team" page and a "Case Studies" section in week 3, that's new scope, and a fair developer will charge for it, often $150 to $500 per added page depending on complexity.
You don't need every sub-page nailed down. You do need the main branches. A quick way to build one: list every question a customer asks you before they buy, then group those answers into pages. That grouping is your sitemap.
Who writes the website copy, you or the developer?
You do, unless you've hired and paid a copywriter. Most web design quotes do not include writing your words for you, and assuming otherwise is the most common reason projects stall.
Design follows content, not the other way around. When I lay out a homepage, I'm shaping space around real headlines and real paragraphs. Placeholder text hides problems: a heading that's perfect at 4 words breaks at 14. Nielsen Norman Group has argued for content-first design for over 20 years for exactly this reason, and you can read their research at nngroup.com.
You have 3 honest options. Write it yourself. Pay a copywriter (expect $75 to $150 per page for a small business site) before the build. Or agree in writing that the developer will write it and pay for that time. What you can't do is stay vague and hope words appear. Owned, approved copy per page is the difference between a build that flows and one that waits on you.
What brand assets does a developer actually need?
A developer needs your logo in a scalable format, your exact colours as hex codes, and the fonts you want, plus any photography you own the rights to.
Here's the practical list:
- Logo as SVG if you have it, or a PNG at least 1000px wide with a transparent background. A logo pulled off a social profile is usually 200px and the wrong format.
- Colours as hex values, not "our blue." A brand usually needs 3 to 5 defined: one or two primary, one accent, plus neutrals. If you don't have them, a designer can define them, but say so up front.
- Fonts, with a note on licensing. Not every font is free to use on a website, and a self-hosted commercial web license can run $50 to $300.
- Photography you have the legal right to use. Stock is fine. Photos scraped from Google are a real liability, and stock-image firms have sued for four-figure settlements over a single unlicensed image.
If you have a brand guide, send it. If you don't, that's fine, just flag it so the designer can build one into the scope instead of guessing.
Which CMS should you pick before hiring?
You don't have to pick the exact platform, but you should know how often you'll edit the site and whether you want to do it yourself. That answer points to the right CMS.
A CMS, or content management system, is the tool that lets you change text and images without touching code. The choice affects cost and how the site is built, so it belongs in the brief.
| If you... | A reasonable fit |
|---|---|
| Rarely change content, want it fast and cheap | A static site, edits go through the developer |
| Run a blog or update more than once a month, non-technical | WordPress or a hosted CMS |
| Sell products | Shopify or a commerce platform |
| Want a custom app with content baked in | A headless CMS with a custom front end |
You don't need the jargon. You need to answer one question honestly: are you going to edit this yourself, and how often? Tell the developer that and let them recommend the platform.
What integrations should you list in the brief?
List every outside tool the site must connect to: booking, payments, email marketing, a CRM, analytics, live chat, anything. Each one is work, and a surprise integration late in a build can add days to the timeline.
The ones people forget until launch week are the ones that hurt. A booking system that has to match your existing calendar. A payment processor your accountant already uses. An email tool with a specific signup form. Each connection has its own quirks, and some third-party embeds slow the page down. That matters: Google found that as page load time goes from 1 to 3 seconds, the probability of a mobile bounce jumps 32%. Their performance guidance at web.dev is worth a look if you want to know why load time gets so much attention (see why load time gets so much attention).
Write the list now, even if it's short. "Stripe for payments, Mailchimp for the newsletter, Calendly for bookings" is a perfect line to have in a brief.
How firm does the timeline need to be?
Firm enough to name a target launch date and the reason behind it. "Before our spring season" or "ahead of the trade show on March 12" gives a developer something real to plan against.
"As soon as possible" is not a timeline. It usually means the deadline is invisible until it's missed. A good brief states the date you need to be live and why, plus how quickly you can turn around feedback. That second part matters more than clients expect. A 3-week build where the client takes 5 days to reply to each review is not a 3-week build; it's closer to 6 (see turn around feedback) (see working with a developer long-term).
Realistic ranges for a small business site: a simple brochure site runs roughly 2 to 4 weeks of build time once the brief is solid, and a larger custom site or web app runs 6 weeks and up. Rush jobs typically cost 25% to 50% more or cut scope. Both are fine if you say so early.
The quick readiness test
Before you send your brief, read it back and ask: could a stranger start building from this without emailing me a single question? If yes, you're ready. If you flinched at any of the 6 items above, fix that one first. It's much cheaper to sort out a missing font file today than to pause a live project in week 4.
If you want a second pair of eyes on a brief before you commit to anyone, that's the kind of thing I'm happy to look at. You can see how the studio approaches web and custom software projects at https://subsecondstudio.com, where the client approves the finished design before paying.
FAQ
How long should a website brief be?
As long as it needs to answer the 6 items, and no longer. One clear page beats 10 vague ones. A solid brief for a small business site is often a single document with the sitemap, links to copy and brand files, and a short paragraph on integrations and timeline.
Can I start a project without final copy?
You can start the discovery and structure work, but design shouldn't finalize on placeholder text. If your copy isn't ready, agree on who's writing it and when before the design phase begins, so it doesn't stall the build.
What if I don't know what CMS I want?
That's fine. You don't need to name a platform. You need to tell the developer how often you'll update the site and whether you want to edit it yourself. That answer lets them recommend the right tool for you.
Get your website designed before you pay. Subsecond Studio designs and builds websites, web apps, and AI tools, and you approve the design before any payment. Get an estimate