Sections every web design proposal needs
The seven sections every web design proposal needs, what to put in each, what to cut, and how to order them so the client reads to the price already convinced.
No card needed. 2 clients and 5 quotes free forever. Unlimited teammates.
Order matters as much as content
The sequence below isn't arbitrary. It's built so the client reaches the price already convinced, understanding first, then approach, then scope, and only then the number. Lead with the price and you're asking them to judge cost before value. Lead with your company history and you've lost them before you start. Get the order right and every section makes the next one land.
1. Summary
One short section that restates the client's situation and goal in their words. This is where you prove you listened. Done well, the client thinks "yes, that's exactly it" and reads the rest as a believer.
Keep it about them, not you. "You're losing mobile enquiries because the current site can't take bookings and loads slowly" beats "We are delighted to present our proposal."
2. Approach
How you'll tackle the project, and why. This is where you show judgement, the reasoning a client can't get from a feature list. Mention your process (discovery, design, build, launch), the key decisions you'd make, and why your way suits their problem specifically. This section is what separates a considered proposal from a template with the name changed.
3. Scope and deliverables
The heart of the commitment: what's included, what they'll receive, and, just as important, what isn't included. A clear out-of-scope list protects both sides and signals experience. Don't skip it to seem generous; vague scope is where projects and relationships go wrong. See in-scope vs out-of-scope.
- List deliverables as concrete things: pages, templates, integrations, migrations.
- Name the exclusions a reasonable client might otherwise assume.
- Reference the full scope of work if it's a separate
document.
4. Timeline
The phases, the key dates, and, critically, what depends on the client. Content, approvals and access are the usual causes of slippage, and if you don't name them as dependencies, their delays become your problem. A timeline with client responsibilities built in sets expectations honestly.
5. Pricing
The number, what it covers, and the payment schedule. Present it with confidence, don't bury it, don't apologise for it, and don't itemise it into forty lines the client can pick apart. Group into a few value blocks. If you want to grow the deal, add optional extras the client chooses. For reaching the figure, see how to price a website.
6. Terms
The guardrails: revision limits, change control, assumptions, and how sign-off works. This section is short but load-bearing, it's what turns a friendly proposal into a real agreement. Summarise revision limits and your change process so there are no surprises later.
7. Next step
End by removing friction. Tell the client exactly what happens when they say yes: sign here, pay the deposit, we book you in. A proposal that ends on a vague "let us know your thoughts" invites the silence covered in why proposals get ghosted. Make the next action a single, obvious click.
What to cut
- Pages about your agency's history. A short credibility note is fine; three pages of awards is
self-indulgent. Prove yourself through the approach section instead.
- Generic filler about "the importance of a strong web presence". The client knows. It reads as
padding.
- Every micro-line of pricing. Group into value blocks.
- Legal boilerplate the client can't parse. Keep terms clear and human; save the long-form
contract for a linked document.
FAQ
Build the proposal once, reuse the spine
Start free in ScopeDeck and assemble proposals from a structure that carries into the build, no card needed.