useful website proposal is not a glossy promise that a supplier can make something modern. It is a shared description of what will be delivered, what the client must provide, how decisions will be made and what happens when reality differs from the original assumptions. The clearer those boundaries are before work starts, the less room there is for surprise invoices, stalled approvals or an argument about whether the project is finished.
The opening should identify the audience, the current problem and the business result the work is meant to support. “Redesign the website” is an activity, not an outcome. A stronger brief might aim to increase qualified enquiries, make a complex service easier to understand, reduce manual booking work or let an internal team publish without developer help. The proposal should also state how that result will be measured after launch.
- Named page templates, features, integrations and content types—not only an estimated page count.
- Responsibilities for research, copy, photography, data entry, migration, analytics and redirects.
- Supported browsers, devices, accessibility expectations and performance targets.
- Explicit exclusions and assumptions, including third-party licences and recurring services.
- A change-control route for work that becomes necessary after the scope is agreed.
A page list on its own is rarely enough. A contact page with one form is different from a routed enquiry system with file uploads, CRM synchronisation, spam protection and conditional questions. The proposal should describe behaviour at a level that lets two suppliers price the same result.
Deposits, stage payments and final payment should correspond to clear events: approval of discovery, acceptance of a design system, a working build on staging, or launch handover. The agreement should explain how review works, how many feedback rounds are included, when silence pauses the schedule and what evidence counts as acceptance. A calendar date without a client-dependency plan is not a delivery promise.
- Who owns the final source code, design files, written content and custom assets?
- Whose accounts hold the domain, hosting, analytics, repositories and third-party services?
- What reusable libraries, fonts, stock assets or open-source licences remain subject to outside terms?
- What documentation, credentials, exports and training are supplied at handover?
- What happens if either party ends the project before completion?
The proposal should distinguish launch work from the period after launch. It should name who handles DNS, redirects, analytics checks, backups and rollback; define what the warranty treats as a defect; and separate defects from maintenance and new features. “Support included” is not a useful promise unless the period, response route and boundaries are stated.
Thebestproposalmakesthedifficultconversationsordinarybeforetheybecomeexpensive.
“Fast”, “accessible” and “SEO-ready” are intentions until the proposal explains how they are checked. Ask which templates and journeys are tested, which tools and manual reviews are used, what counts as complete and which evidence is handed over.
- A page and template inventory, including content responsibility.
- Functional journeys with roles, states, errors and integrations.
- Browser, device, accessibility and performance expectations.
- Rendering, metadata, redirects, sitemap and analytics requirements.
- Milestones tied to demonstrations and acceptance.
- Client-owned accounts, intellectual property and source handover.
- Launch responsibilities, warranty boundary and ongoing support options.