What a good project brief contains

Most briefs are feature lists. Five pages, a contact form, a blog, an admin panel, mobile responsive. Everything in that list is true and none of it says what the project is for, which means the people building it are guessing about the only thing that matters.

A brief that produces good work does something different. It describes a problem clearly enough that someone else could propose a solution you had not thought of.

Start with what is not working

One paragraph, in plain language, about the situation rather than the fix.

"We get around forty enquiries a month and close maybe three. We think people cannot tell what we actually do."

That is more useful than ten pages of specification, because it lets someone challenge the assumption. Perhaps the site is fine and the follow-up is the problem — which is more often the case than anyone expects. A feature list cannot surface that. A problem statement can.

Say who it is for

Not a demographic. A recognisable person with a situation.

"An operations manager at a 30-person manufacturer who has been told to fix a process and does not know whether they need software or just a decision."

Everyone building can picture that person. "SMEs in the NCR region" describes nobody, and work aimed at nobody reads like it.

Say what would count as success

Specific and checkable. "More enquiries" is not a target. "Ten qualified enquiries a month, up from four" is.

And write down what would count as failure, which almost nobody does and which sharpens everything. "If it looks better and the enquiries stay the same, this was a waste." That sentence changes how a project gets built.

A brief that cannot be failed cannot be succeeded at either. It can only be delivered.

Say what you will not do

Constraints are the most useful part and the most often left out.

The budget, as a real range. The date, and what happens if it moves. The tools you are keeping regardless. The things that are decided and not open — a brand you will not change, a system you cannot replace.

Withholding the budget to "see what they come back with" produces proposals aimed at an imagined number, and a round of re-scoping that costs everyone a fortnight. Say the range. A partner worth having will tell you what fits in it.

If you honestly do not know the budget, work it backwards from the problem instead of leaving it blank. Take what the problem costs you in a year: the enquiries lost, the hours of rework, the orders mistyped. Then say what share of that you would pay to remove it. That is a range a builder can respond to, and it is more honest than a number picked to sound reasonable. The cost calculator will show you what projects of your kind usually cost, so the range you state is not wildly off before the first call.

Say what already exists

Every project starts somewhere, and the brief usually forgets to say where.

The current site or system, and who can get into it. If the old developer holds the hosting login and has stopped answering, say so on day one. It changes the first week of the plan.

The data that has to move. Not "our products" but how many, in what form. Four hundred products in a spreadsheet with photos in a shared folder is a day of work. The same four hundred living only on the old site, with descriptions nobody has a copy of, is a week.

What it has to connect to. The accounting software, the payment gateway, the WhatsApp number, the courier account. Each one is a dependency with its own logins and its own quirks, and the joins between systems are where projects slip.

Whether the words are written. This is the line most briefs leave out and the one that moves dates most. If the text and photos do not exist yet, say who will produce them and by when. If the honest answer is "we hoped you would", say that too, because writing is real work and it belongs in the quote rather than in an argument halfway through.

Say who decides

One name. Others can advise, but one person consolidates feedback and decides. Briefs that skip this produce projects where three people give conflicting direction and the work oscillates.

Also say how fast that person can respond. If reviews will take a week because of how your business runs, that is not a problem — it is a fact the timeline should be built around. Pretending otherwise just means the plan is wrong from day one.

When you do not need a brief at all

For a small site with content ready, a written brief is overkill. A forty-minute call and a one-page summary of what was agreed does the same job, and we will write that summary ourselves.

The brief earns its effort when money is large, several people are involved, or you cannot yet say what the problem is. In that last case, do not force a document. Pay for a short discovery step first. It costs less than building the wrong thing, and sometimes the answer is that you do not need a new build.

What to leave out

Solutions, mostly. If you have already decided on the answer, say so and say why — but if you are open, leave it open. The value of hiring people who have solved this before is that they may know a smaller way.

Examples of sites you like, without saying why. Three links are useless. "We like this one because the pricing is clear immediately" is worth more than thirty.

Page counts. The structure should come out of the problem, not into it.

The test

Give the brief to someone who does not know your business and ask what problem it is solving and who for. If they can answer, it is a good brief.

If they can only tell you what is being built, you have written a specification — and specifications produce exactly what was asked for, which is only useful if the request was right.