Website projects rarely blow out because the development was hard. They blow out because scope was ambiguous, content arrived late, or approval kept moving. All three are decided at the briefing stage, before anyone writes a line of code.
A good brief does not need to be long. It needs to answer these questions clearly.
What is the site for?
One sentence. Generate enquiries, sell products, support existing customers, establish credibility for a tender process. If a site is trying to do four things equally, it will do all of them poorly. Rank them.
Who is it for, and what do they need to see?
Describe the two or three real audiences and what each needs before they act. A prospect comparing three suppliers has different questions to an existing customer looking for support. Both may need to be served, but not by the same page.
What pages exist, exactly?
A written page list is the single best defence against scope creep. Not "a services section" — the actual pages, named. Every addition after sign-off is then a visible, priceable change rather than an argument.
Who is writing the content, and by when?
This is the number one cause of delay in website projects, by a wide margin. Design and build move quickly; content sits waiting for someone internal who has a day job. Decide early whether copy is being written by you or by the agency, and set a date for each page.
- Name a single person responsible for content delivery.
- Agree a date per page, not one date for everything.
- Decide whether photography is being commissioned or licensed.
- Confirm who supplies logos, brand assets and guidelines.
Who approves, and how many rounds?
Name the decision-maker. If approval requires a committee, say so upfront and build the time in. Agree the number of revision rounds included, and what happens beyond that. This conversation is uncomfortable for ten minutes and saves weeks.
A project with three named dates and one named approver will beat a project with a beautiful mood board and neither.
What has to integrate?
Payment gateways, booking systems, CRM, email platform, inventory, accounting, analytics. Each integration carries assumptions about access, data format and testing time. Listing them at brief stage prevents the late discovery that the booking system has no public interface.
What happens after launch?
Decide before launch who handles updates, backups, security patching, hosting and support. A site with no owner degrades within a year. Whether that is your team with training or an ongoing maintenance arrangement, agree it while everyone is still paying attention.
Answer those seven questions in writing and you have a brief that most agencies would be delighted to receive — and a project substantially more likely to land on time.
Want a hand with this?
We do this work every day for businesses in Australia and worldwide.