A website estimate should name what will be delivered and what must be ready for it to happen. Page count alone is a poor proxy: a simple editorial page and a customer portal may each count as one page while requiring very different design, integration and verification work.
Separate a website from an application
A focused landing page usually has one primary journey. A business website adds service structure, content templates and enquiry paths. An application introduces user accounts, roles, state and integrations. Describe the intended behaviour first, then identify which templates and systems support it.
For a lead-generation site, define the enquiry path, required form behaviour and how enquiries reach the team. For a portal, specify permissions, data ownership and error handling. Animation and imagery are design scope; they do not substitute for the requirements that determine implementation complexity.
- Existing assets and content: migration, writing, approvals and imagery.
- Design scope: templates, interaction detail, responsive behaviour and accessibility.
- Integration scope: forms, CRM, booking, payments, authentication or existing APIs.
- Editing scope: who changes content, which fields are editable and what publishing process is required.
Estimate milestones and their dependencies
A focused landing page, a multi-page website and a web application need different estimates. Review the content, design decisions, integrations and acceptance criteria before assigning dates. A useful proposal separates prototype review, implementation and production launch, with the dependencies for each milestone.
Agree the first review date, feedback windows, launch criteria and external dependencies in the proposal. A delayed brand decision or unavailable API can move the launch even when development is progressing. State what the schedule assumes rather than burying those dependencies in an optimistic date.
The delivery process explains how scope and review dates are agreed. A working increment can support earlier decisions without implying that every project has a fixed prototype duration.
Ask what the price includes
No public budget range is provided here because approved project pricing has not been established for publication. A useful proposal separates design, content preparation, implementation, integrations, verification and handover. It also lists external licences, hosting and recurring services.
- 01Provide the business goal, current site, content inventory and important user journeys.
- 02Identify required integrations and whether access and documentation are available.
- 03Agree editing needs, supported browsers/devices and launch checks.
- 04Review the written scope, assumptions, exclusions and change-request process.
- 05Confirm ownership, handover, the included support window and ongoing maintenance options.
Compare proposals on that scope, not only on the total. A lower estimate may exclude migration, integration retries, accessibility work or post-launch ownership. A higher estimate should explain the additional work in terms a buyer can inspect.
Content editing and ownership need explicit decisions
A developer-managed content site can be appropriate for infrequent updates. A non-technical publishing team may need a CMS or existing editorial platform. Choose the editing approach based on who will use it; do not imply that every code-based site includes a visual editor.
Agree who owns repositories, domains, hosting accounts and integration credentials. A handover should show how to deploy, update content, manage configuration and diagnose common failures. Ownership of delivered code does not transfer ownership of third-party software or licences.
Clarify launch QA and continuing support
Development includes checks of the agreed build, while additional independent QA, automation and security expand the scope. Name the important journeys and the verification evidence expected at launch. A generic “tested” line does not tell you what was checked.
The proposal should name the included support period, covered defect fixes, exclusions and how issues are reported. New content, features, integrations and ongoing monitoring may require separate maintenance. Do not infer a duration or response commitment that is absent from the agreement.
Measure the result you wanted from the website
Define a baseline for loading behaviour and the enquiry funnel before changing the site. Performance checks can show technical improvement, while enquiry conversion needs event tracking, a consistent observation period and attention to traffic mix. Neither page speed nor a redesign alone guarantees more qualified leads.
See web development for the delivery scope and send the current site and requirements for a written estimate. Published case narratives describe the work available to inspect; numerical before/after results need genuine measurement records.
