Asking for a website quote can feel as though you need to arrive with every decision already made. Some companies send little more than "we need a new website". Others produce a long specification that fixes the content management system, page structure and features before anyone has examined the underlying problem.
Neither extreme gives a supplier a particularly solid foundation. A useful brief is not a blank sheet, but it is not a completed technical blueprint either. It explains what the company needs to achieve, the context the website must work within and the boundaries that are genuinely fixed. It also leaves room for better solutions to emerge.
Decide what the website needs to change
Start with the reason for the project. "Our website looks old" may be true, but it does not say what a successful replacement should improve. The more useful questions are about business and user outcomes:
- Who are the priority audiences?
- What are they trying to find, understand or complete?
- Where does the current website make that difficult?
- What should become easier for customers or staff?
- How will the company recognise meaningful improvement?
An outcome might be reducing avoidable support enquiries, helping customers choose the right service, increasing the quality of sales enquiries or allowing an internal team to publish content without developer support. "Build it in a particular CMS" is not an outcome. It is one possible response.
The GOV.UK guidance on discovery is written for public services, but its central principle travels well: understand the problem, users and constraints before committing to a solution. Its guidance on user needs also recommends treating unsupported opinions as assumptions to be tested. A commercial website project may be smaller and less formal, but the distinction between evidence and assumption is still useful.
Bring real constraints into the brief
Leaving technical choices open does not mean withholding practical information. Suppliers need to know about the environment in which the website will operate. Otherwise, each proposal may be based on a different imaginary project.
Useful information can include:
- the available budget or a realistic range;
- deadlines and the business reason behind them;
- systems the website must exchange information with;
- content, customer data, URLs or search visibility that may need protecting during migration;
- security, privacy, accessibility or regulatory requirements;
- brand rules and existing design work;
- hosting, domain, software or supplier contracts already in place;
- the skills and capacity of the people who will manage the website.
A realistic budget range is not an invitation to spend every penny. It helps suppliers recommend an approach that is proportionate, rather than designing first and discovering later that the proposed solution is unaffordable.
Not every point will be fully known. Say where information is incomplete rather than turning a guess into a requirement. A supplier can then identify what needs investigation, what creates risk and what may affect the price.
Decide who owns the decisions and the work
A website quote also depends on what the company will contribute. Who will write, review and approve the content? Who can make decisions when departments disagree? Who will provide access to analytics, existing systems and third-party accounts? How much time can subject specialists realistically give the project?
These details affect the schedule and scope just as surely as the number of templates or integrations. A supplier can price its own work; it cannot reserve time in somebody else's diary. Roled's article on why many website rebuilds fail looks more broadly at unclear goals, stakeholder alignment, content and internal effort. The quotation stage is an early opportunity to make those responsibilities visible.
Keep solution-shaped decisions open where possible
Companies sometimes prescribe a platform, plugin or architecture because it feels more concrete than describing the need. That can narrow the available options too soon and make suppliers price compliance with the specification rather than solve the problem.
Try expressing the requirement without naming the implementation. "The marketing team must be able to create and schedule campaign pages" is more useful than "use this page-builder plugin". "Customers must be able to book and receive confirmation" leaves more room than specifying a particular booking component before its suitability has been checked.
Some technology decisions really are fixed. An internal team may already support a particular platform, a parent company may impose standards, or an integration may have firm technical requirements. State the reason, not just the preference. The GOV.UK introduction to choosing technology highlights the need to consider existing systems, data, constraints, lock-in and future change. Those are sensible questions for private-sector projects too, even though the government process itself may not apply.
Ask the proposal to expose uncertainty
A credible proposal does not need to pretend that every unknown has vanished. For a straightforward brochure website, a supplier may be able to quote clearly from the initial brief. A complex rebuild involving integrations, migration or uncertain user journeys may need a discovery stage, a range, or a phased estimate before a dependable build price is possible.
Ask each supplier to make clear:
- what is included and excluded;
- which assumptions affect the price;
- what research or discovery is proposed;
- who is responsible for content and migration;
- how changes to scope will be handled;
- which third-party costs continue after launch;
- what ownership, support and maintenance arrangements apply.
This makes proposals easier to compare. Two totals can look similar while covering very different amounts of work, and the lowest figure may simply contain the largest pocket of unpriced uncertainty. Roled's guide to website ownership and control explores the related questions around domains, code, data, accounts and handover arrangements.
Before sending the brief, try dividing it into two headings: decided and still open. Under the first, record outcomes, evidence, responsibilities and genuine constraints. Under the second, record assumptions and choices that need expert investigation. That gives a supplier enough truth to propose responsibly without asking the company to design the answer in advance.
