How to Write a Brief for a Software or Website Project

A good brief answers three questions: what problem the software solves, who uses it, and what must be true for it to count as a success. Features come after, and often the right features are not the ones you had in mind when you started writing.

This matters more than it sounds. The brief is the single document that decides whether the quotes you receive are comparable, whether the build finishes on budget, and whether anyone can tell at the end if it worked. Knowing how to write a project brief is the cheapest risk control available to you, and it costs an hour.

What follows is the template we ask clients to fill in, what belongs in it, what does not, and the mistakes that cause projects to drift.

Why do most briefs fail?

Because they describe a solution instead of a problem. "We need a website with a booking page, a blog, a members area, and a dashboard" tells a developer what to build, but nothing about what it is for, so nobody can tell you that three of those are unnecessary or that the fourth is the hard part.

Two things follow. Every quote you receive is a guess, priced defensively and impossible to compare with the next one. And once building starts, every disagreement about scope has no reference point, because the brief never said what success meant.

The three questions a brief must answer

What problem does this solve? Describe the situation as it is today, including the manual work, the errors, and what it costs you. Be specific about how often it happens.

Who uses it? Every group, not just customers. Staff, admin, and whoever maintains it later.

What must be true for this to be a success? Something you can measure within ninety days of launch. "Looks professional" is not a success criterion. "Bookings arrive without any phone calls" is.

What a brief is not

A brief does not say how the work gets done. Not the framework, not the platform, not the layout, not the database. Those belong in the document that comes back to you, usually called a scope of work, a proposal, or a work outline, and writing it is the job of whoever you hire.

The division is simple. You own the problem, because only you know your business. They own the solution, because only they know what the work costs. When a client writes the solution into the brief, the team ends up quoting on instructions instead of understanding, which is how projects end up delivering exactly what was asked for and none of what was needed.

The one exception is a genuine constraint. If it must run on the platform your staff already maintain, or connect to the accounting system you already pay for, say so. That is a fact about your business, not a design decision.

Design follows the same rule. Say whether a logo, colors, and fonts already exist and are fixed, whether this must match an existing site, which devices your customers actually use, and any accessibility requirement. Add two references with a sentence on what you like about each. But leave the layout, the navigation, and the color choices alone, because those are answers to the problem you have just described, and they cannot be answered well before anyone has read it. If no brand exists yet, say that as a fact. It usually means a separate design phase in the proposal, and it is far better to learn that early than to discover it halfway through.

The brief template

Copy this into a document. Four parts, two pages, short answers. Every heading needs one line at minimum.

Part one: the problem What happens now, step by step, including the spreadsheets, the messages, and the parts that depend on one person remembering. How often it happens, and what it costs you in time, money, or lost work.

Part two: the people Everyone who touches it, and roughly how many of each. A system with three kinds of user is a different project from one with a single user.

Part three: what success means Two or three statements you can measure within ninety days of launch, each with a date. Then the short list of what must exist at launch, the longer list of what can wait, and the things you have deliberately decided not to do for now.

Part four: the practicalities Budget range and deadline, with the reason the date matters. The systems it must work with, named. What data and content already exists and who is preparing it. Any rule you cannot break, such as regulation, hosting, or who maintains it. And the one person who can approve decisions.

Two optional lines that help more than they should: a reference or two with a sentence on exactly what you like about each, and anything you tried before that did not work.

What it looks like filled in

Below is the same template completed for a real sounding case: a physiotherapy clinic that needs a website with online booking. Two pages of work, and every line of it is something only the owner could tell you.

How do you write the success part properly?

This is where most briefs go soft, so give it ten extra minutes.

Take the problem from part one and turn it into a number. If ten hours a week go into retyping orders, success is that the retyping is gone and the time is under one hour. If the problem is missed enquiries, success is that every enquiry gets a reply within an hour and none are lost.

Write two or three of these with a date on each. They become the acceptance test at the end, which protects both sides: you know what you paid for, and the team knows when they are finished.

What does a website project brief need that a software brief does not?

Clarity about audience and content, since that is where website projects stall.

Who the site is for and the one action they should take. Who writes the copy, and by when. Whether photography exists or needs producing. Which pages actually matter, as opposed to the ones that exist because every site has them. Whether search visibility is a goal, and for which phrases. And who updates it after launch, because a site nobody can edit goes stale within a year.

Common mistakes

No budget range. Owners withhold it fearing they will be charged the maximum. What actually happens is that you receive proposals for the wrong size of project. A range lets a good team tell you what is achievable within it, or that it is not enough, which is useful either way.

Everything is a must have. If nothing can be dropped, nothing can be prioritized, and the first delay becomes a crisis.

No decision maker named. Approval by committee is how a four week build takes four months.

A deadline with no reason. If the date exists because of a season, an event, or a contract, say so. Real deadlines change the plan. Invented ones only add pressure.

What does a good reply to your brief look like?

Not a longer document. A reply that proves the problem was understood.

Look for three things. They restate your problem in their own words, and it matches what you meant. They ask at least one question you had not thought of, or flag something that will cause trouble later. And they offer options with trade offs rather than a single number: a smaller version that launches sooner, a fuller one that costs more, and an honest note on which part carries the risk.

How quickly it arrives tells you little. An experienced team can read a clear two page brief and know the shape of the work within an hour. What matters is whether the reply engages with your problem or simply prices your list.

There is a related reason to keep the brief short. A long document full of instructions about how to build the thing puts good people off, because it reads as a project that will argue over every decision.

Before you send it, check these

Could someone outside your business read it and explain what you do? Does every must have connect to a measurable success criterion? Is there at least one thing on the not doing list? Have you named the systems you already use, the budget range, and the person who approves decisions? And is it two pages rather than ten?

If yes, send it. The replies you get back will finally be worth comparing.

The quieter point

A brief is not paperwork. It is the moment you decide what problem you are actually paying to remove, and every hour spent on it saves several during the build.