Web Design Proposal Template: What to Include to Win More Projects

A good web design proposal answers five questions in two pages or less: what you'll build, how you'll get there, what it costs, how long it takes, and what happens if the client changes their mind halfway through. Skip any of those five and you either lose the project to a competitor who was clearer, or you win it and pay for the ambiguity later in unpaid revisions. Below is a proposal structure you can copy today, plus the reasoning behind each section so you can adapt it instead of just filling in blanks.

Why most web design proposals don't land the project

Most freelancers write proposals backwards. They open with a paragraph about their agency's "passion for design," list every service they offer whether the client asked for it or not, and bury the price on page four next to a paragraph of legal boilerplate copied from a template they found in 2019. By the time the client gets to the number, they've already decided you're generic.

The pattern shows up in three ways, and if you've been freelancing for more than a few months you've probably lived through all of them.

First, the proposal that goes unanswered. You spend two hours on a beautifully formatted PDF, send it, and hear nothing for three weeks. Not a rejection, not a question, just silence. Usually this means the client couldn't figure out what they were actually agreeing to, so they moved on to whoever made the decision easy.

Second, the proposal that turns into a negotiation spiral. The client replies asking "can you also do the logo" or "does this include hosting setup" and you realize your scope section was too vague to answer without a follow-up call. Every unanswered question is a day added to your sales cycle.

Third, and the most expensive one: the proposal that gets accepted but doesn't match what the client remembers agreeing to. Three weeks into the project they ask why the blog isn't included, or why there's no e-commerce, and you're stuck explaining that it was never in scope, while they're stuck feeling like they got less than they paid for. Nobody wins that conversation.

A proposal template fixes the first two problems. A clear scope section, paired with the contract template that follows it, fixes the third.

What to include in a web design proposal (9 sections)

1. One-line summary of the problem you're solving. Not "website redesign for [Company]" — that's a title, not a summary. Write what the client actually told you in the discovery call: "Your current site doesn't reflect the rebrand and isn't generating enough contact form submissions from mobile visitors." This tells the client you listened before you quoted a number.
2. Scope, broken into pages and deliverables, not vague phrases. Replace "full website design" with a list: homepage, about page, 3 service pages, contact page, blog template (content not included), mobile and desktop responsive layouts. If something is explicitly out of scope, name it: "Does not include copywriting, photography, or SEO content strategy." This single line prevents more disputes than any clause in your contract.
3. Process and timeline, in weeks, not vague phases. "Discovery: Week 1. Wireframes: Week 2. Design: Weeks 3-4. Client review: Week 5. Development: Weeks 6-7. Launch: Week 8." A client who can see the calendar trusts the estimate more than one who reads "4-6 weeks depending on feedback."
4. How feedback rounds work. State the number of revision rounds included (two is standard for most freelance projects) and what happens beyond that — usually an hourly rate for additional rounds. If you're using a visual feedback tool, mention it here: it tells the client exactly how reviews will happen, which removes one more unknown before they sign.
5. Price, shown as one number or a clear range, never "starting at." "Starting at $3,500" reads as bait. If the project truly can't be priced without more discovery, say that explicitly and offer a paid discovery phase instead of a fake number.
6. Payment schedule. 50% deposit before work starts, 25% at design approval, 25% at launch is the most common freelance structure and it protects both sides. State exactly what triggers each payment.
7. What the client needs to provide, and by when. Logo files, brand guidelines, copy, product photos, access credentials. Add a line that says delays in receiving these materials shift the timeline accordingly — this is the clause that saves you from being blamed for a delay you didn't cause.
8. Why you, specifically. One short paragraph, two or three relevant past projects with results if you have them ("increased mobile form submissions by 40%"), not a generic bio. Link to your portfolio rather than pasting screenshots into the PDF.
9. Clear next step. "Reply to this email to confirm, and I'll send the contract and deposit invoice within 24 hours." Every proposal needs one unambiguous action, or the client defaults to doing nothing.

Here's the same structure as a quick reference, with what each section is actually protecting you against:

Section  ·  What it prevents

Problem summary  ·  Sounding generic, getting ignored

Scope list  ·  "I thought that was included" disputes

Timeline  ·  Client assuming it's faster than it is

Revision rounds  ·  Unpaid extra revisions

Price  ·  Sticker shock, ghosting after the call

Payment schedule  ·  Chasing invoices, working unpaid

Client deliverables  ·  Being blamed for a delay you didn't cause

Why you  ·  Losing to a cheaper, less specific competitor

Next step  ·  The proposal sitting unanswered in an inbox

How to price the project inside the proposal

Pricing is where most proposals lose confidence. Freelancers either round down out of fear of rejection or pad the number so much the client feels overcharged before the first call. Two approaches work better than guessing.

Fixed-price by deliverable works well for defined scopes — a 5-page marketing site, a portfolio redesign, a landing page. You quote the whole project as one number tied to the scope list in section 2. If the client asks for something outside that list later, it's a change order, not a fight. Our guide on how to price web design projects walks through the math freelancers actually use to land on a number, rather than picking one out of the air.

Value-based pricing works when the project has a clear business outcome attached — a redesign meant to increase conversion rate, or a site meant to support a product launch. You price against the value of that outcome to the client's business, not your hours. This only works if you can name the outcome specifically in section 1, so the client sees the connection between the number and the result.

Whichever approach you use, put the number in the proposal itself. Clients who have to ask "so what does this cost" after reading a proposal have already mentally deprioritized it.

If a client comes back asking for a lower price, don't just cut the number and keep the scope the same — that trains every future client to negotiate, and it tells this one that your first price wasn't real. Instead, offer a smaller scope at the lower price: fewer pages, one revision round instead of two, or a phased approach where phase one covers the essentials and phase two is a separate quote later. This keeps your rate intact while still giving the client a way to say yes at a number they're comfortable with.

Scope, revisions, and the awkward money conversations

The proposal is also where you set the tone for every difficult conversation that might come later. Two things are worth being explicit about, even though it feels uncomfortable to bring them up before you've even started.

Scope creep prevention starts here, not in the contract. If your scope list in section 2 is specific, then when a client asks for "just one more page" three weeks in, you have language to point back to rather than an argument to have from scratch. Our breakdown of scope creep in web design covers how to handle the request once it happens — but the proposal is what makes that conversation short instead of tense.

Late payment and pausing work is worth one sentence in the proposal, even if it feels aggressive to write: "Work pauses if an invoice is more than 7 days overdue." Clients rarely push back on this line when they read it upfront, but they absolutely notice if it shows up for the first time in an invoice reminder after they're already three weeks late.

Real freelancer example: how Mara turned a vague inquiry into a signed project

Mara, a freelance designer working mostly with local service businesses, used to send a generic one-page PDF for every inquiry — same wording, same price range, sent within an hour of the first call to look responsive. Her close rate hovered around one in five. Prospects would go quiet, or come back three weeks later asking questions she thought the PDF had already answered.

She switched to the structure above for a dental practice rebrand. Her proposal opened with the specific problem the owner had described on the call — an outdated site that made a modern practice look 15 years old, with a contact form that barely got used. The scope section listed exactly six pages, named what was out (no blog, no online booking integration in phase one), and laid out a five-week timeline with two review rounds. The price was one number: $4,200, with a 50/25/25 payment split.

The client replied the same day with one question — whether online booking could be added as a phase two — and signed two days later. No scope disputes came up during the project because every "is this included" question had already been answered before the contract was signed. Mara now reports her close rate sits closer to one in three, and she spends less time answering pre-sale questions by email because the proposal already did that work.

Bottom line

A web design proposal wins projects when it reads like a plan, not a pitch: a specific problem, a specific scope, one clear price, and one clear next step. Spend your effort on section 2 (scope) and section 5 (price) — those two sections prevent more lost deals and more mid-project disputes than anything else in the document. Once it's signed, move straight into a contract that mirrors the same scope language, so nothing gets reinterpreted between the proposal and the paperwork.

Frequently asked questions

How long should a web design proposal be?

One to two pages for most freelance projects. Anything longer usually means the scope section is vague and you're compensating with extra explanation. A specific two-page proposal converts better than a generic five-page one.

Should I send a proposal before or after a discovery call?

After. A proposal written without a call is a guess dressed up as a quote, and clients can tell. Even a 15-minute call gives you the specific problem statement that should open section 1.

Do I need a separate contract if I already sent a detailed proposal?

Yes. A proposal is a sales document; a contract is the legal agreement that protects both sides if something goes wrong. Use the same scope wording in both so there's no gap between what was proposed and what was signed. See our web design contract template for the fields a proposal doesn't need to cover.

How many revision rounds should I include in a web design proposal?

Two rounds is standard for most freelance projects: one after the initial design concept, one after development. State it explicitly in the proposal, along with the hourly rate for anything beyond that, so it's never a surprise mid-project.

Should I show my price as a range or a fixed number?

A fixed number whenever the scope is defined enough to support one. Ranges read as uncertainty to most clients, and they tend to anchor on the low end regardless of what actually gets delivered.

What's the biggest mistake freelancers make in web design proposals?

Vague scope language. "Full website design" or "modern responsive site" means something different to every client. List actual pages and deliverables, and name what's explicitly excluded, so there's no gap between what they imagined and what you quoted.

Can I reuse the same proposal template for every client?

Reuse the structure, not the content. The problem statement in section 1 and the scope list in section 2 need to be specific to that client's project every time — that's what makes a proposal read as considered rather than copy-pasted.

How do I collect feedback on the proposal itself before the client signs?

Some freelancers send the proposal as a shared document or PDF and ask the client to leave comments directly on unclear sections rather than replying with a long email. It's a small step, but it turns "I have some questions" into specific, pinned feedback you can answer in one pass instead of several email rounds.

What if the client wants to negotiate after receiving the proposal?

Adjust the scope, not just the price. Offer a smaller version of the project at the lower number, or split it into phases, rather than discounting the same deliverables. This protects your rate for future clients and keeps the relationship framed around value instead of haggling.

Stop guessing what your client means by "make it pop." [Try dotts free →](https://dotts.se)