Prepare the source pack
Choose the proposal kind and supply the buyer brief, approved evidence, delivery assumptions and commercial terms. For RFP work, retain the issued requirements and separate known answers from missing evidence.
Web Design Proposal Template
The section-by-section structure of a web design proposal that actually wins the project — discovery, sitemap and information architecture, design approach, build scope, timeline, deliverables, and pricing, with what belongs in each. Use it as a checklist, or generate a tailored version from your own discovery and scoping notes with Gixo Arc.
A web design proposal is the document a studio or freelance designer sends a prospect to win a website project. A strong one moves from their problem to your plan: it opens with the goals and pain points you uncovered in discovery, maps out the site's structure, shows how you'll approach the design and build, sets a realistic timeline and clear deliverables, and states the investment and terms. The template below covers all of it. Gixo Arc builds this structure from your actual discovery notes and scoping files rather than a generic prompt, so the first draft reflects the real project — then you review and price it.
Arc · real output
From a supplied scope to a proposal you can inspect.
Read a real exported proposal alongside the brief Arc received. The example keeps supplied scope, commercial assumptions and reviewer responsibility visible.
Consulting proposal: repairs satisfaction measurement, Harbourside Housing Association
A ten-week advisory engagement for an invented housing association: situation, approach and phases, a requirement-by-requirement compliance matrix, deliverables, timeline, team, terms, and a fee built phase by phase from the bidder's day rates, with the days of each role shown.
Inspect the source brief or data
Propose a ten-week advisory engagement for Harbourside Housing Association, on behalf of Larkfield Analytics Ltd, that answers the association's brief: review the current repairs survey, recommend how to measure repairs satisfaction by contractor, and leave a reporting approach for the repairs team and the board. Build the fee for each phase from the standard rates in the evidence file (the days of each role times the day rate) and show those days. Add nothing the evidence file does not state. Put a notice on the cover page that the buyer and the bidder are fictional and the proposal is a worked example. Inputs: the buyer's document (brief-harbourside-housing.md); the bidder's evidence file (larkfield-evidence.md); commercial terms: value 46,000 to 52,000 GBP, valid for 60 days, payment terms 'Invoiced monthly in arrears, payable within 30 days.'; deal context: The buyer and the bidder in this proposal are fictional, and this proposal is a worked example. The engagement lead presents to the buyer's board in the ninth week.
Read the sample review notes
A separate reviewer agent read its 177 claims against the bidder's evidence file, the buyer's brief and the deal terms: 115 are supported, 58 add design detail or an inference, 4 are in no input (it calls the fee fixed) and none contradicts one. Every price line recomputes. It is not a person's review.
Review the proposed response
Inspect scope, exclusions, requirements and price assumptions. Use reviewable edits and saved comparisons; an unresolved buyer question needs an owner or an explicit qualification.
Package the reviewed version
Inspect the actual PDF, Word or HTML output. Tracked delivery activity and a recorded deal outcome answer different questions; verify the recipient, permissions and current approval state before sharing.
Buyer requirements and response ownership
Keep buyer RFP files separate from bidder evidence and approved reusable answers. Inspect extraction coverage, requirement source locations, questionnaire previews and submission limits. Response work can carry an SME owner, due date, escalation owner and required reviewer decisions. Compare an addendum with the source before changing a response.
Commercial schedules and recurring totals
Review each line's quantity, rate, unit, optional status and one-off, monthly or annual recurrence. Inspect recurrence totals and the estimated first-year total separately. Currency, supplied tax input and commercial assumptions need review. When importing Business metrics, select and review the source values before applying them to the schedule.
Buyer edition and submission package
Choose the current saved response or an approved edition. Inspect retained attachments, filled questionnaires, the compliance matrix and the package preview. A release manifest identifies stored delivery bytes. For tracked links, review recipient access, expiry, password and permissions separately from delivery activity and the recorded opportunity outcome.
A draft or readiness check is not approval of pricing, legal terms or a delivery commitment. Arc proposal drafting does not imply CRM, CPQ or tax-calculation automation.
What a winning web design proposal includes: the website proposal template structure
Eight sections, in order. Keep it client-first: lead with their goals and the problem the new site has to solve, not your studio bio.
1
Discovery & goals — the problem to solve
Two or three sentences naming what the new site has to achieve in the client's terms — more qualified leads, a redesign that finally reflects the brand, a site that works on mobile, an outdated stack that's slowing them down. This is the hook: show you understood the brief before you talk about pixels. Write it last, once the rest of the proposal makes the case.
2
Sitemap & information architecture
How the site will be organised — the page structure, primary navigation, and key user journeys from landing to conversion. A clear sitemap early signals that you're designing for how visitors actually move through the site, not just how pages look. It also anchors the scope: everyone agrees which pages exist before design starts.
3
Design approach & mockups
How you'll get to the look and feel — wireframes for layout, then visual design against the brand, plus the number of design concepts and revision rounds included. If you have relevant work or a moodboard direction, reference it here. Being explicit about revision rounds up front is what keeps a design phase from drifting into endless tweaks.
4
Build scope & technology
What you'll actually build and on what stack — the CMS or platform (e.g. WordPress, Webflow, a headless build), responsive behaviour, integrations (forms, CRM, analytics, payments), and any custom functionality. Spell out what's in and out of scope; unstated assumptions about "just one more feature" are where fixed-price web projects lose money.
5
Timeline & milestones
A phased plan with milestones — discovery, design sign-off, build, content load, testing, launch — and honest dates for each. Make the client's dependencies visible too: content, feedback, and approvals from their side drive the schedule as much as your work does. Naming who owns what by when prevents the "we're waiting on you" standoff.
6
Deliverables
The concrete list of what the client receives — designed and built pages, responsive layouts, a CMS they can edit, source files or handoff assets, browser and device testing, and a defined launch. Include what's handed over at the end (access, training, documentation) so "done" is unambiguous. Vague deliverables are where a build and its client part ways.
7
Pricing & tiers
Your commercial terms, framed as an investment against the goals in section 1. Whether it's a fixed project fee, a tiered set of packages, or a build-plus-care-plan, tie the price to the scope so it reads as value, not cost. Offering two or three tiers — and naming a payment schedule against milestones — lets the client choose a level and protects your cash flow.
8
Terms & next steps
What's needed to start, ownership and licensing of the final site and assets, hosting and post-launch support, and a single clear call to action. Cover revision limits and change-request handling so scope creep has a path. Make saying yes easy: one obvious next step — sign, pay the deposit, book kickoff — beats a wall of legal text. Keep detailed terms in an appendix or linked agreement.
Website redesign proposal: what changes when the site already exists
A redesign runs on the same eight sections, but four things move that a new build never has to price. Get them into the scope and the timeline, or they arrive as unbudgeted work in week six.
1
The audit comes first, and it is priced work
Before a redesign can be scoped you have to know what is actually there: how many pages exist rather than how many are in the navigation, which of them get traffic, what the current stack does that nobody documented, and which templates are load-bearing. Put the audit in the proposal as its own phase with its own deliverable and its own fee. A redesign quoted from a homepage screenshot is a redesign quoted blind, and the difference usually shows up as a page count nobody agreed to.
2
Content migration is the line that breaks the estimate
Say who is moving the content, page by page, and in what form. Automated migration works where the old and new structures rhyme and fails wherever the old site improvised — one-off layouts, inline styling, PDFs standing in for pages. Name the page count you priced against, state what happens to pages beyond it, and say explicitly whether rewriting or reformatting content is included. Clients almost always assume it is.
3
Redirect mapping is scope, not a launch-day task
Every URL that changes needs a 301 to its nearest equivalent, and the mapping is manual wherever the structure changes rather than the styling. Price it against the page count from the audit, name who signs the map off, and put post-launch monitoring of 404s and lost rankings in the deliverables with a defined window. This is the most commonly omitted line in a redesign proposal and the one the client discovers in their analytics a month after launch.
4
Parity scope: what must still work on day one
List the behaviour the current site has that the new one has to keep — forms and where they deliver, integrations, tracking and consent, gated content, language variants, and anything a search engine already ranks. Everything not on that list is a new feature and is priced as one. A written parity list is what turns "it looks great but our lead form stopped working" from a dispute into a change request.
What makes a web design proposal win (and what loses it)
Lead with their goals, grounded in real discovery. The proposals that win open on the client's specific problem and what the site has to achieve, not on the studio's portfolio. Real notes from an actual discovery call make sections 1 and 2 credible; generic claims make the whole document feel like a template.
✓ Be specific about deliverables and build scope — vague scope is where fixed-price web projects go over.
✓ Name your revision rounds and change-request process before design starts.
✓ Make the client's dependencies — content, feedback, approvals — part of the timeline.
✗ Don't leave technology, integrations, or "who owns the files" unstated.
✗ Don't bury the price, the payment schedule, or the next step under boilerplate.
✗ Don't send the same document to every prospect — a proposal that could be anyone's is nobody's.
Web design proposal template: FAQ
What should a web design proposal include?
A discovery and goals section, a sitemap and information architecture, your design approach and revision rounds, the build scope and technology, a phased timeline with milestones, a clear deliverables list, pricing, and terms with a next step. The strongest ones lead with the client's specific problem and what the site must achieve, backed by real discovery notes, rather than the studio's portfolio.
How long should a web design proposal be?
Long enough to cover the eight sections and no longer — typically a handful of pages. Depth belongs in the scope, build details, and deliverables; everything else should be tight. A focused proposal a busy prospect actually reads beats a 30-page document they skim.
How do I price a web design proposal?
Tie the price to the scope and the goals, not to hours. Fixed project fees are common for defined builds; tiered packages let the client pick a level, and a care plan or retainer suits ongoing maintenance. Set a payment schedule against milestones — a deposit to start, payments at design sign-off and launch — to protect cash flow on both sides.
How do I stop scope creep on a web project?
Define it in the proposal. State which pages and features are in scope, how many design concepts and revision rounds are included, and how change requests are handled and billed. Making the client's dependencies — content, feedback, approvals — explicit in the timeline keeps both sides accountable and gives out-of-scope requests a clear path rather than a fight.
Can I generate a web design proposal automatically?
Yes — Gixo Arc builds this structure from your uploaded discovery and scoping files, so the draft reflects the actual project rather than a generic template. It produces a professional first draft in minutes; you still review, price, and tailor it before sending.
Is a web design proposal template the same as a website proposal template?
Yes. Web design proposal template, website proposal template, and website design proposal template all describe the same document — the phrasing varies by who's searching, but the structure doesn't: discovery and goals, sitemap and information architecture, design approach, build scope, timeline, deliverables, pricing, and terms.
What is a website proposal?
A website proposal is the document a studio or freelance designer sends a prospective client to win a website project. It names the goals the site has to hit, maps the structure it will have, sets out the design and build approach, fixes the scope and the timeline, and states the price and the terms. It is the same document a client might call a web design proposal, and the eight sections above are what it contains.
How do I scope a website redesign proposal?
Start from an audit you have priced as its own phase: the real page count, what traffic each page gets, and which templates are load-bearing. Then scope the three things a new build never has — who migrates the content and for how many pages, who maps and signs off the 301 redirects, and what parity means on day one across forms, integrations, tracking, gated content and language variants. Anything outside that parity list is a new feature, and pricing it as one is what stops a redesign quietly absorbing a second, unbudgeted project.
Does this structure work for a website redesign, not just a new build?
Yes. For a redesign, the discovery section should name what's driving the change — an outdated design, a broken mobile experience, a rebrand — and the sitemap and information architecture section should show what's changing versus what's staying. The design approach, build scope, timeline, deliverables, pricing, and terms sections apply the same way they would for a new site.
Should a website design proposal and a website development proposal be separate documents?
Only when different teams do the work. A website design proposal then covers discovery, the sitemap and information architecture, the design concepts and the revision rounds, and a development proposal covers the build, the platform, integrations, testing and launch. Each one should name the hand-off between them, such as signed-off designs and the files the developers receive, so neither side assumes the other priced it. If one studio does both, send one proposal with all eight sections so the price covers the whole project.
Updated
More from Gixo