What should a web design proposal include?
A web design proposal should include the problem the client is trying to solve, the scope of work, the deliverables, the timeline, the price, the terms, and the next step. If you leave out any of those pieces, the client has to guess what they are buying, and guesswork slows decisions.
The shortest useful answer is this: your proposal needs enough detail to let a client compare options, understand your process, and approve the work without a lot of back-and-forth. Proposify’s web design template, for example, uses sections for an overview, scope of services, timeframe, pricing, terms, and sign-off. HoneyBook and Indy both show proposals as part of a larger client workflow that includes contracts, payments, and files, which is a good reminder that a proposal is not just a PDF. It is a decision document. Proposify, HoneyBook pricing, Indy pricing.
Why this question matters
Freelance web designers usually do not lose projects because they cannot design. They lose them because the proposal is vague.
A vague proposal creates avoidable questions:
- What exactly is included?
- How many pages?
- Is copywriting included?
- What happens after launch?
- What if the client changes the scope halfway through?
- Why does this price make sense?
If the proposal does not answer those questions, the client often delays, asks for revisions, or compares you on price alone.
The sections a web design proposal should include
1. A short summary of the client’s goal
Start by showing that you understood the project.
Write 3–5 sentences that say:
- what the client wants to change
- why it matters to their business
- what outcome the project should support
Example:
The current site is hard to update, the homepage does not make the offer clear, and the contact flow is not helping leads take the next step. This project will replace the old site with a cleaner brochure site that explains the service, builds trust, and makes inquiries easier.
This is not fluff. It tells the client you listened and gives the rest of the proposal context.
2. The scope of work
This is the most important section.
List the work in plain language. Be specific enough that someone could tell whether a request is in scope or out of scope.
A good scope section often includes:
- number of pages or templates
- content types you will design
- responsive behavior
- CMS setup
- contact forms
- basic SEO setup
- migration from the old site, if included
- accessibility or performance work, if included
Bad example:
- redesign website
- improve pages
- make it modern
Better example:
- redesign the homepage, about page, services page, and contact page
- set up one blog post template in the CMS
- design mobile and desktop layouts for each page
- add one contact form and connect it to the client’s inbox
- make minor content edits provided by the client
That version is easier to price and easier to approve.
3. Deliverables
Scope and deliverables are related, but not the same.
The scope says what work you will do. The deliverables say what the client will receive at the end.
Examples of deliverables:
- homepage mockup
- full website design in Figma
- developed website on staging
- launch-ready site with up to 5 pages
- style guide
- reusable page template
- handoff notes
If you hand off files, say so. If you only deliver the live site, say that instead. Clients should not have to ask what they can keep.
4. Timeline and milestones
A proposal should show how the project will move.
Use milestones such as:
- discovery
- content gathering
- design concept
- revisions
- development
- QA
- launch
You do not need a minute-by-minute schedule. You do need enough structure for the client to understand when decisions are due and what happens first.
Example:
- Week 1: discovery and content collection
- Week 2: homepage and inner page design
- Week 3: revisions and approval
- Week 4–5: development and launch prep
If you know the client’s responsiveness affects timing, say that.
5. Price and payment terms
Do not hide the price in a paragraph.
Make the investment easy to find and easy to understand.
Include:
- project fee
- what is included in that fee
- payment schedule
- deposit amount
- what happens if the project expands
If you charge by phase, show each phase separately. If you offer optional add-ons, list them separately so the client can see the base project first.
Example:
- Discovery and planning: $500
- Design and build: $2,500
- Launch support: $300
- Total: $3,300
Then state the payment schedule:
- 50% to start
- 25% after design approval
- 25% before launch
That gives the client a clear path from approval to payment.
6. Assumptions and exclusions
This section prevents scope creep.
Include what is not included, such as:
- copywriting
- brand identity work
- product photography
- e-commerce setup
- ongoing maintenance
- extra revision rounds
- page counts beyond the agreed scope
You do not need to sound defensive. Just be clear.
Example:
This proposal does not include copywriting, photo sourcing, or post-launch maintenance. Those services can be added if needed.
7. Revision policy
Clients need to know how feedback works.
State:
- how many revision rounds are included
- what counts as a revision
- what counts as a new request
Example:
Two rounds of revisions are included for the homepage design. Additional rounds or new page requests will be quoted separately.
That line alone can save a lot of confusion later.
8. Terms and responsibilities
This is where you define the working relationship.
Include the basics:
- who provides content
- who approves design
- how communication will happen
- what happens if the client delays feedback
- cancellation or rescheduling terms, if relevant
You do not need to turn the proposal into a legal brief. But you do need enough terms to keep the project moving.
9. Proof or relevant examples
A short proposal is stronger when it includes a sample of past work, a process note, or a brief explanation of why your approach fits the client.
You do not need a long portfolio section.
A few lines can do the job:
- similar projects you have handled
- the kind of problems you solve
- the process you use
- one or two examples of work that look like the project at hand
Keep it relevant. A client reviewing a redesign proposal does not need to see every type of project you have ever done.
10. Clear next step
End with one action.
Examples:
- approve the proposal
- sign the agreement
- pay the deposit
- book the kickoff call
If the client has to wonder what happens next, the proposal is not finished.
A simple order that works
If you want a straightforward structure, use this order:
- Client goal summary
- Why you are a fit
- Scope of work
- Deliverables
- Timeline
- Price
- Terms and exclusions
- Next step
That order moves from understanding the problem to approving the work.
What not to include
A web design proposal should not try to do everything.
Leave out:
- long marketing copy that does not help the decision
- vague claims like “high-quality design” without specifics
- too many options in one document
- technical details the client does not need yet
- hidden pricing or unclear add-ons
The goal is clarity, not length.
A practical checklist before you send it
Before you send a proposal, check whether it answers these questions:
- What problem are we solving?
- What exactly is included?
- What is not included?
- What will the client receive?
- When will each phase happen?
- How much does it cost?
- How and when is payment due?
- What happens if the scope changes?
- What should the client do next?
If the answer to any of those is unclear, revise the proposal before it goes out.
Sources and useful references
- Proposify: Web Design Proposal Template
- HoneyBook pricing and proposal features
- Indy pricing and proposal features
A better proposal is a clearer decision
For freelance web designers, the best proposal is the one that makes the client’s decision easier. That means fewer vague promises, more specifics, and one clean path to approval.
If you want help turning that structure into a reusable system, the next step is the Web Design Proposal Kit from Scope Letter.