Website Proposal

What a website proposal is

A website proposal is the document a studio, agency, or freelancer sends to win a website project. It sets out what the new (or rebuilt) site needs to achieve, which pages and features are in scope, how the design and build will be approached, what it will cost, and how long it will take. It turns a loose "we need a new website" conversation into a concrete plan the client can approve and budget for.

Unlike a generic sales pitch, a website proposal lives or dies on specifics: the page list, the integrations, the launch date, and what happens after go-live. The clearer those are, the easier it is for the client to say yes — and the fewer scope arguments you have later.

Goals and success metrics

Open with what the site is for, not what it looks like. A website is a business tool, so name the outcomes in measurable terms and agree how you will judge success after launch:

• Commercial goals — more enquiries, more online sales, higher average order value, fewer support calls.
• Success metrics — conversion rate, page load time, organic traffic, checkout completion, bounce rate.
• Baseline — record where the current site sits today so the improvement is provable, not just claimed.

If search visibility is a major driver, say so explicitly and consider pairing the build with an SEO proposal so technical SEO is designed in from the start, not bolted on later.

Sitemap and scope of pages

This is the section that prevents 80% of scope disputes. Spell out exactly which pages and templates you will build, and just as importantly, what is not included:

• Page list / sitemap — every URL or template type (home, category, product, blog, contact, checkout).
• Templates vs pages — distinguish reusable templates (e.g. one product template) from one-off pages.
• Content responsibility — who writes copy and supplies images. Be explicit; this is where projects slip.
• Out of scope — e.g. ongoing content production, photography, translation, third-party app subscriptions.

Design and build approach

Explain how you work so the client knows what to expect and when they will see things:

• Discovery — goals, audience, competitors, content audit, technical requirements.
• Design — wireframes or low-fidelity layouts first, then high-fidelity mockups of key templates for sign-off.
• Build — front-end development, responsive behaviour, accessibility, and CMS or commerce setup.
• Review and QA — cross-browser/device testing, content population, and a structured client review round.

State how many design and revision rounds are included. "Unlimited revisions" is a trap; two named rounds per template is fair and reviewable.

Integrations, CMS and analytics

Most modern sites are assembled from platforms and services, so list them. This sets technical expectations and surfaces any licences or accounts the client must provide:

• CMS / e-commerce platform — what powers the site (headless CMS, WordPress, Shopify, etc.) and why.
• Payments and fulfilment — payment gateways, shipping, tax, and inventory systems for commerce builds.
• Marketing and data — email/marketing tools, CRM, and analytics so results are measurable from day one.
• Migrations — content, products, redirects, and historic URLs that must move across cleanly.

Timeline, phases and pricing

Break the work into phases with dates so the project feels real and schedulable, and itemise the price so the client can see what each part costs:

• Phases — discovery, design, build, content/QA, launch. Tie payment milestones to phases.
• Dependencies — flag where your timeline depends on client sign-off or content delivery.
• Pricing — fixed price per phase or per workstream, with payment terms and what triggers extra cost.

Hosting and post-launch support

Launch is the start, not the end. Say clearly who hosts the site, who can edit it, and what support looks like once it is live:

• Hosting — where it lives, who pays, and any platform/licence fees passed through.
• Handover — admin access, documentation, and training so the client is not dependent on you for everything.
• Support / care plan — a defined post-launch window for fixes, plus an optional monthly maintenance plan.
• Ownership — confirm what the client owns at the end (the site, the code, the content, the accounts).

Common mistakes to avoid

• Pricing a design, not a result. Anchor the proposal to business goals, then justify the cost against them.
• A fuzzy page list. "A modern website" invites endless additions; a named sitemap protects both sides.
• Ignoring content. Most sites stall because copy and images are late. Assign content ownership up front.
• No post-launch plan. Clients fear being stranded after go-live. Spell out support, hosting, and ownership.
• Forgetting migrations and redirects. On a rebuild, lost URLs cost rankings; budget for them explicitly.