A website brief that fits on one page
A thick requirements document doesn’t guarantee a good website. What belongs on a single page so the agency understands the task and you know what you’ll get.
Many people sit down to write a requirements document before ordering a website and quickly get stuck. The templates online run to dozens of pages: hosting requirements, browser lists, a description of every button. It feels like without all that, the agency will build the wrong thing.
In practice, a long spec written before talking to the developers rarely helps. It describes solutions rather than the problem, and it’s often outdated by the first meeting. A short document that answers the key questions is far more useful. The agency will clarify and write up the details itself; that’s its job.
Why one page is enough
The job of that first document isn’t to describe the whole site. It’s to explain what the business is, what you want to achieve, and within what limits. That’s enough for the agency to propose an approach, estimate the scope and ask the right questions.
A detailed description of pages, features and scenarios will appear anyway, as the site structure and prototype in the early stages of the work. It’s just created together, drawing on the developers’ experience, rather than alone before the project starts.
A short document is also easier for everyone on your side to read. Leadership, marketing and sales can agree on one page quickly, while discussing thirty pages takes weeks, and by then half the items will have changed.
What goes on that page
Here’s what to write. A few sentences per item, no more.
About the company and the product. What you do, what you sell, what sets you apart. For a real estate developer: which project, what class of housing, how many phases, what stage sales are at.
Who the buyers are. Not “everyone who needs an apartment,” but more specific: families moving out of a rental, buy-to-let investors, people relocating from other cities. Where they come from and what matters to them when choosing.
The goal of the site. What should happen as a result: viewing requests, calls to the sales office, mortgage consultation bookings. One or two main goals beat five equal ones.
What exists today. The current site, if there is one, and what’s wrong with it. Which materials are ready: logo, brand identity, copy, photos, renderings, floor plans.
What’s essential. The features without which the site makes no sense: an apartment finder, CRM integration, a calculator, a customer portal. Only what’s truly necessary, not everything you liked on other sites.
Competitors. Two or three projects buyers compare you with, and how you differ from them, or would like to.
Constraints. The launch date and why it matters. A ballpark budget. Who on the company side makes decisions and signs off on the work.
What not to write
Some things in a first document do more harm than good:
- choosing the technology and CMS, unless there are hard reasons;
- exact colors and fonts, which get decided in design;
- a description of every page before the task has been analyzed;
- generic phrases like “a modern, user-friendly website.”
The last point deserves a word. Nobody orders an outdated, unfriendly website, so those words carry no information. Give an example instead: a site you like, and what exactly you like about it.
Examples help more than descriptions
Two or three sites you like and one or two you don’t, with short notes, often tell the agency more than a page of musings about style. They don’t have to be from your industry. What matters is explaining what exactly grabs you: how the search works, how information is presented, what feeling the site leaves. If there are materials buyers have already seen, a brochure, a project presentation, ad layouts, attach those too.
What happens next
With a document like this, the first meeting is productive. The agency asks follow-up questions, suggests how to solve the problem, and after the analysis puts together a detailed site structure, feature list and work plan. That document, agreed by both sides, becomes the basis of the contract.
It helps if by then you also have a list of questions for the agency: how the work is organized, how many rounds of revisions, who your point of contact will be, what post-launch support covers. The answers matter as much as the estimate itself.
A good brief describes the business problem. It doesn’t design the website for the developer.
If you’d like to check whether everything important made it into your project description, send it over as is, even as a rough draft, and we’ll go through what’s missing together.