Start with the problem, not a list of features
A website project brief is a shared starting point for your team and the vendors you invite to propose. Its job is to explain what needs to change and give vendors enough information to recommend a sensible approach. If each vendor has to guess at your priorities, their proposals may describe very different projects.
Open with a short description of your organization, the people the website serves and why the project is happening. Separate the problem from your preferred solution. For example, “Visitors struggle to find our program information, and staff cannot update it easily” is more useful than “We need a new homepage and a page builder.” You can mention a preferred tool, but explain whether it is a requirement or a suggestion.
Name a few outcomes you care about, such as making services easier to find, reducing routine enquiries or giving staff a manageable publishing process. These goals help vendors decide what work matters most. They also give you a basis for evaluating proposals beyond appearance.
Define the work and its boundaries
Describe what the website needs to include: its approximate number of pages, main types of content, important forms, and any connections to other systems. Say what you already have, such as a content inventory, brand guidelines, photography or an existing website that needs to stay available during the project. If content writing or migration is needed, state who you expect to do it.
Be equally clear about what is outside the project. A small organization might need a clearer services website but not a member portal. Stating that boundary keeps one proposal from including a portal while another prices only public pages. Where you have not made a decision, label it as an open question and ask vendors to explain their recommendation.
Include practical requirements that affect the work: who will maintain the site, which devices visitors commonly use, any languages to support, and what staff need to be able to edit. Ask vendors to describe how they will address accessibility, basic security, backups and handover. These are easier to compare when every proposal discusses them.
Share constraints vendors cannot guess
A useful brief names the people who will approve decisions, the time staff can devote to reviews, and any events that shape the schedule. If you have a target launch period, explain why it matters. Vendors can then flag whether the timeline is realistic and show where your team’s feedback or content will be needed.
Consider sharing a budget range. It helps vendors propose work at an appropriate scale rather than designing around an unknown ceiling. If the range is flexible, say what might justify spending more. If you cannot provide one, ask vendors to separate essential work from optional improvements and explain the assumptions behind their price.
Also disclose known technical constraints, such as an existing domain, hosting arrangement or software your team must keep using. You do not need to solve every technical question in the brief. You do need to distinguish firm requirements from preferences so vendors know where they can suggest alternatives.
Ask every vendor to answer the same questions
Give vendors a response structure. Ask each one to outline their proposed approach, deliverables, project stages, your team’s responsibilities, likely risks and ongoing costs. Request an itemized price or clearly defined phases, including what is excluded. This makes differences visible: one proposal may include content migration and staff training, while another assumes your team will handle both.
Use a shared question period if vendors need clarification. Send substantive answers to everyone you have invited, so no one is working from a different version of the project. For example, if a vendor asks how many documents need to move to the new site, your answer may materially affect every estimate.
A brief should still leave room for expertise. Ask vendors to identify assumptions and suggest changes to the scope where they see a simpler path to your goals. Comparable proposals do not have to be identical; they need to make the reasons for their differences clear.
Compare proposals against the brief
Before proposals arrive, decide how you will assess them. A simple review sheet might cover understanding of your goals, suitability of the approach, clarity of scope, accessibility and maintenance plans, team responsibilities, timeline and total cost. Agreeing on these factors in advance can keep a polished presentation from overshadowing important practical details.
Read each proposal alongside the brief and note missing answers. Check whether prices cover the same work, including content, testing, training and post-launch support. When they do not, ask for clarification rather than assuming the cheaper figure offers better value. A short follow-up conversation can also show how a vendor explains trade-offs and responds to uncertainty.
Keep the brief concise enough for your team to maintain. Its value is not in predicting every detail of the finished website. It is in giving vendors a common account of the problem, a clear boundary for the work and a fair way to explain how they would help.
