Start with the job the website needs to do
A website estimate becomes useful when it describes a specific outcome. A visitor booking a consultation, comparing a product, and managing an account are three different tasks. Each needs different content, interactions, and testing. Before counting pages, write down who the site serves and what a successful visit should allow that person to accomplish.
For example, a small consultancy might need visitors to understand its services, evaluate its approach, and submit a project brief. That gives the project a clearer boundary than a request for a modern website. GOV.UK's guidance on scoping services recommends mapping the overall user journey to understand which tasks belong together. The same principle is useful when planning a commercial website. Read the scoping guidance.
Count distinct layouts and behaviors
A page count tells only part of the story. Ten articles using one template may require less design work than three pages with different interactive tools. List the types of pages, the reusable sections they share, and the behavior each needs. Include search, filtering, forms, navigation, and any customer account features.
For a service business, the list might include a homepage, service detail template, article template, contact page, and a reusable enquiry form. Add the less visible states: a form error, a successful submission, and a page that cannot be found. These details make estimates easier to compare because each proposal describes the same work.
Make content ownership explicit
Decide who supplies the copy, photography, illustrations, and downloadable files. A site built around approved material has a different workload from one that also needs messaging, editing, image selection, and content migration. Put those responsibilities in the brief before design starts.
Review the existing material as well. An old site may contain duplicated pages, outdated downloads, or images that need replacement. Create a simple inventory with a decision for each item: keep, revise, combine, or retire. If the team needs a content management system, identify exactly what editors should be able to change themselves.
Investigate integrations before treating them as simple
A request to connect a CRM can mean sending a single enquiry or synchronizing contacts, permissions, and historical records. Describe the information that moves, which system owns it, and what should happen if the connection fails. Include access requirements and recurring third-party charges in the planning discussion.
When an integration is uncertain, a small technical investigation can produce a more defensible estimate. The output should be concrete: a tested connection, documented limitations, and the remaining implementation work. Discovery should answer an open question that could change the project.
Include the work around launch
A delivery plan should make room for review, browser and device checks, accessibility evaluation, deployment, and handover. Define who approves content and how feedback will be collected. A single consolidated review is easier to act on than conflicting edits arriving through several channels.
Discuss what happens after launch: who updates content, maintains dependencies, monitors forms, and handles a broken integration. Separate the initial build from ongoing services so the budget reflects both the release and the work needed to keep it useful.
Compare assumptions alongside the total
Ask each proposal to state its deliverables, assumptions, dependencies, and acceptance criteria. If the available budget is fixed, prioritize the essential visitor journey and phase optional functionality. A narrower first release can still feel complete when its core task works from beginning to end.
The best next step is a short scope document. Include the audience, desired action, page types, content responsibilities, integrations, and launch requirements. That document gives both sides a shared basis for discussing cost, timing, and changes.