Explain the website's role in your organisation
A website may present a company credibly, generate enquiries, support sales, book services, publish resources or serve existing customers. The order of these objectives influences architecture and budget. Name the primary audience, the decision they should be able to make and what happens after they submit a form or select an action.
Create a realistic content inventory
A page list is a start, but it does not show who writes the copy, whether images exist, how many languages are needed or how many content types repeat. A portfolio with twenty projects is not one page from the perspective of migration and checking. State what remains, what is rewritten, what must be created and who approves each asset.
- Pages and repeated types: services, projects, articles, team members or locations.
- Existing copy, new copy and responsibility for writing it.
- Photography, video, illustration, licences and missing assets.
- Languages, translations and how they are approved.
- Content that must be migrated from the current website.
Describe behaviour, not only the feature name
“Form”, “customer account” or “CRM integration” can mean very different things. For each one, describe fields, roles, notifications, transferred data and what should happen on error. If the external system has not been selected or access is not yet available, mark the dependency. A precise estimate cannot compensate for an unknown integration.
Clarify who will operate the website
State what the team should edit without a developer: pages, services, articles, SEO, forms or users. Mention access levels, approval before publishing and training needs. Administration is not merely a panel; it includes content modelling, validation, preview, history and responsibility for updates.
Include requirements that do not appear in mock-ups
Accessibility, performance, technical SEO, analytics, consent, security, backup and device compatibility affect implementation and testing. Not every project has the same risk level, but these subjects should not be discovered in the final week. Attach any legal requirements or internal policies to the brief.
Set responsibilities and a realistic schedule
A launch date is not enough. Who provides feedback, how quickly, who makes the final decision and which other teams must be consulted? Include periods when key people are unavailable and any external dependencies. An honest schedule contains time for content, feedback, revisions, testing and release preparation, not just design and code.
The cheapest proposal may describe the smallest part of the problem, not the most efficient solution.
Compare assumptions, not only totals
Ask the proposal to separate phases, deliverables, review rounds, third-party services, maintenance and exclusions. Check who does the work, how it is tested, what you receive at the end and who owns the accounts and code. Large price differences often become understandable when assumptions and responsibilities are compared side by side.
- What scope is included and what is explicitly excluded?
- Which assets and access must the client provide?
- How many feedback rounds are included and how is work approved?
- What testing, launch, training and warranty are included?
- Which recurring costs exist after launch?
- How are scope changes estimated and approved?