Web design proposal template: what to include (with example)

A good web design proposal template has eight parts: a short summary of the client's goal, the scope, deliverables, a timeline, pricing with optional add-ons, assumptions and exclusions, payment terms and a clear way to accept. If your current proposal is missing any of these, that gap is usually where projects stall or scope creep begins.

This guide walks through each section in the order a client reads it, explains what to write and what to leave out, and ends with a complete priced example you can adapt.

Why the structure matters more than the design

Clients rarely read a proposal top to bottom on the first pass. They open it, look for the total, scan the timeline, and then go back to check whether the scope matches what they asked for. A proposal that answers those three questions quickly gets approved faster than one that is beautifully laid out but makes them hunt.

That is why the order below is deliberate. Each section answers the question the client is most likely to have at that point. You can restyle the template however you like, but resist the urge to move pricing to the very end behind ten pages of agency history. Nobody signs because of your founding story.

There is also a practical reason to standardise. When every proposal follows the same skeleton, you write them faster, you can compare win rates between projects, and you notice quickly when a deal is drifting outside your usual scope.

The sections to include

1. Project summary. Two or three sentences in the client's language, not yours. "Rebuild the site so customers can book a table and order online from their phone" beats "Deliver a responsive, conversion-optimised digital experience." If the client cannot recognise their own problem in the first paragraph, they stop trusting the rest.

2. Scope. List what you will do as concrete work: number of page templates, which CMS, how many rounds of revisions, whether you migrate existing content. Vague scope is the single biggest cause of disputes later.

3. Deliverables. What the client will actually have at the end: a live site on their domain, a style guide, editor training, access credentials. Deliverables are different from scope. Scope describes the work; deliverables describe the result.

4. Timeline. Use phases with week ranges rather than exact dates, because start dates move. A typical structure is Discovery (week 1), Design (weeks 2 to 3), Build (weeks 4 to 6) and Launch (week 7). State what you need from the client at each phase, such as content and feedback within three business days.

5. Pricing. Break the price into three to six line items so the client can see where the money goes. Mark anything that is not essential as an optional add-on the client can toggle on or off. More on this in the example below.

6. Assumptions and exclusions. This section protects you. Write down what you are assuming (the client supplies copy and photos, hosting is on their account) and what is not included (paid plugins, ongoing SEO, translation). Three to five bullets is enough.

7. Payment terms. The most common split for small web projects is 50% to start and 50% at launch. Say how revisions beyond the included rounds are billed, and when invoices are due.

8. Acceptance. End with one clear action. A typed-name acceptance with a consent checkbox is usually enough for small projects and is far easier for the client than printing and scanning a PDF.

What to leave out

Long case studies, team bios and process diagrams belong on your website, not in the proposal. Link to them if you must. Every extra page is another place for the client to find a reason to delay.

Also leave out alternative packages unless the client asked for them. Three tiers of the whole project often cause more indecision than they resolve. Optional add-ons on top of one recommended scope do the same job with less friction. We cover that approach in optional add-ons: the easiest way to raise your average project value.

Finally, avoid legal boilerplate copied from a long contract. Keep the proposal readable and attach or link your full terms separately if you need them.

A complete example with numbers

Here is a realistic proposal for a café that wants a new site with online ordering.

Project summary: replace the current five-page site with a faster, mobile-first site and let customers place pickup orders online.

Scope: discovery workshop, sitemap for six pages, two homepage design concepts with one revision round, build on Webflow, migration of existing menu content, basic on-page SEO, launch and one hour of editor training.

Pricing:

• Discovery and UX: $1,800
• Visual design: $3,200
• Build and launch: $3,600
• Optional: online ordering setup, $1,400
• Optional: photography half-day, $650

The base project is $8,600. If the client selects both add-ons the total becomes $10,650. In practice, clients who see a clearly priced add-on next to the core work choose at least one of them more often than clients who are offered the same extras later by email, because the decision happens while they are already saying yes.

Timeline: Discovery week 1, Design weeks 2 to 3, Build weeks 4 to 6, Launch week 7.

Assumptions: the client provides menu text and logo files; hosting is on the client's Webflow account; the online ordering add-on uses the client's existing payment provider.

Not included: ongoing content updates, paid ads, translation.

Payment terms: 50% ($4,300 for the base scope) to start, 50% at launch. Additional revision rounds are billed at $95 per hour.

Turning the template into a habit

Write the template once, then change only the summary, scope details and prices for each client. Keep a short library of line items you reuse, with your standard descriptions and prices, so you are not rewriting "Build and launch" from scratch every week.

Track two numbers: how long it takes from sending to acceptance, and how often clients pick an add-on. If acceptance takes more than a week, the scope is probably unclear. If nobody picks add-ons, they may be priced too high or described too vaguely.

Start from a ready-made version

If you would rather not build this structure yourself, ProposalKit includes a website redesign template with every section above, optional add-ons the client can toggle, and typed-name acceptance. You can browse the templates or create a free account and send your first proposal today.