How to write a brief for a web project

You have a web project in your head. Maybe it is a new app, a rebuild, or a vague sense that the current thing is holding the business back. Now you need to describe it well enough that a few teams can quote it, and well enough that the right one says yes. The blank document is intimidating, so most people reach for the thing they can write quickly: a list of features. That is the brief that gets you wildly different quotes and a partner who builds exactly what you asked for instead of what you needed.

A good brief is not a spec. You are not designing the system; that is the agency's job. You are giving them enough context to ask smart questions and price the work honestly. The best briefs are short, blunt, and a little uncomfortable, because they admit what you do not yet know. Here is what to put in one.

Lead with the goal, not the feature list

The single most useful sentence in any brief is the one that explains what success looks like for the business. "We want online booking" is a feature. "We are losing bookings because customers call after hours and never call back" is a goal. The second one tells a good team what problem to solve, and they will often solve it more cheaply and cleverly than the feature you imagined.

Write down the outcome you are buying. More signups. Fewer support tickets. A site that stops embarrassing you in sales meetings. A platform your team can actually update without calling a developer. When the goal is clear, a thoughtful partner can push back on features that do not serve it and suggest ones you did not think of. A list of features invites order-taking. A goal invites a conversation, and the conversation is where the value is.

Give a real budget range

This is the part everyone wants to skip, and it is the one that costs you the most. Founders hide the budget because they are afraid the number will simply be spent. The fear is understandable; the silence is worse. Without a range, every agency is guessing at a different project, and you end up comparing a £15k quote against a £150k one for "the same" brief.

A budget range is not a blank cheque. It is a constraint, and constraints are how you find out whether someone is honest. A good team will tell you what is realistic in your range, what would have to wait, and where you would get the most for the money. If a project genuinely cannot be done well for what you have, you want to hear that early, not three sprints in. If you are unsure what numbers are even sane, our breakdowns of what it costs to build a SaaS and the fixed-price versus hourly trade-off will get you to a sensible range before you write a word.

Separate must-haves from nice-to-haves

Every brief contains two kinds of requirements, and conflating them is how budgets quietly double. The must-haves are the things without which the project has not launched at all. The nice-to-haves are everything you would love but could ship in version two. Most people list them in one undifferentiated pile, all marked, implicitly, as essential.

Do the sorting yourself before anyone quotes. Put a small number of genuine must-haves at the top: the things that, if missing, mean you would not pay. Put everything else under a heading that literally says "nice to have, later." This single act of editing does two things. It keeps the first quote affordable and the first launch achievable, and it tells a prospective partner that you think in priorities rather than wish lists. Teams that ship for a living respect a buyer who can tell the difference, and it is the same instinct behind shipping a focused MVP first instead of everything at once.

Name the timeline and what is driving it

"As soon as possible" is not a timeline; it is a feeling. A useful brief gives a date and, more importantly, the reason behind it. "We have a trade show in October and want something to demo" is a real constraint a team can plan around. "Sooner is better" tells them nothing and usually means the deadline will materialise later as a surprise.

Be honest about what is fixed and what is flexible. If the date is immovable, scope is the thing that flexes, and a good partner will help you decide what makes the cut. If the date is soft, say so, because that buys you better engineering and fewer corners cut. Either way, the timeline belongs in the brief, not in the kickoff call.

Say who owns the decisions

Projects do not usually stall on the code. They stall on the wait for an answer. A brief that names the decision-maker, the person who can approve scope and sign off on direction, removes the most common source of delay before it starts. If three people have to agree on every choice, say that too, because it changes how a team plans the work and how long it will really take.

While you are at it, write down a few examples of sites or products you admire, and a line on why. "I like how clean this checkout feels" is more useful than a mood board, because it points at the underlying quality rather than the surface. Show the things you dislike as well. Knowing what makes you wince is as informative as knowing what you love, and it spares everyone a round of revisions.

The takeaway

A good brief is an act of clarity, not completeness. Lead with the goal, give a real budget range, separate the must-haves from the someday-maybes, name a timeline with a reason behind it, and say who gets to decide. Do that and the quotes you get back will be comparable, the conversations will be sharper, and the team you choose will be choosing the real project rather than a hopeful sketch of one.

If you would rather not write it cold, that is fine too; the right partner helps you finish the thinking. You can see how we turn a rough brief into a plan on our how we work page, and our guide to the questions to ask before hiring developers covers the other side of the table. When you are ready, tell us what you are trying to build and we will ask the questions that make the brief better. That is the good kind of lazy: an hour of clear thinking up front that saves you months of building the wrong thing.