Free Web Design Proposal Template
A web design proposal covers the project scope, approach, pricing, payment terms, timeline, and sign-off so the build can start on agreed terms.
Share template
A site rebuild usually starts with one worry: the new thing will work, but every small change will still mean calling the developer. This web design proposal keeps the build legible, so the scope, the handover, and what happens after launch get agreed before anybody commits to the work or the price. The pages sit under Lora headings with Inter body text, with an ink-blue palette and a green call to action that keeps the sign-off hard to miss.
The proposal opens with Overview, then explains who’s doing the work, shows recent projects, and spells out the build approach from discovery through launch. The scope sections stay in plain English, including Approved written scope, the functional parts like forms, payments, or bookings, and what goes into the handover pack, so the client can see what they’ll be able to update without asking. Pricing comes next with a single option, Site plus flows, then the proposal closes with the signature step and the terms that usually cause surprises: payment stages, revisions, third-party services, ownership, and what gets fixed after launch.
- Overview Frames what the site needs to do day to day, then points to the scope, timeline, and cost that follow.
- Recent projects Gives a few short examples of past builds, including what changed and how the client managed updates afterward.
- Approved written scope Defines pages, key flows, integrations, and the edges of the job that keep the price fixed.
- Pricing Holds the single priced option and the fixed-price note, so you only swap in your numbers and what the tier includes.
- Next steps Carries the signature and fee summary, and explains what has to happen after acceptance to schedule the build.
Once the wording and numbers are right, you send it, the client signs online, and the accepted copy becomes the version both sides work from. You replace the template pricing with your own, then adjust the scope and terms so they match what you’ll actually build and support.
We went from spending hours on every proposal to creating fully customized ones in under 5 minutes. That's not an exaggeration - we timed it.
What to include in a web design proposal
| Part | What it covers |
|---|---|
Overview | Sets the expectation for a site that can be updated day to day, then points to the scope, timeline, and pricing that make that possible. |
Who you are working with | Introduces the builder and explains the focus on a fixed scope, supported tools, and a handover the client can use. |
Recent projects | Collects short project snapshots that show the kinds of rebuilds and automations covered, and what the client could manage afterward. |
Workshop bookings site | Describes a bookings flow and admin view, including how sessions, capacity, and payments get tracked without a separate spreadsheet. |
Service business enquiries rebuild | Covers an enquiry setup with routing and confirmations, plus a structure the client can update safely. |
Catalogue and payments setup | Outlines a small catalogue with checkout and order tracking, plus an example quote about handover and making changes in the admin area. |
Our approach | Explains the delivery stages from discovery and scope through design, build, review, and launch, including how progress and revisions get handled. |
Approved written scope | Defines what gets built in plain English, including pages, key flows, integrations, and the limits that keep the price fixed. |
Forms, payments, or bookings | Details the functional parts of the site, the admin screens and data structure behind them, and what the handover pack includes. |
Pricing | Holds a priced items block for the single option, so you replace the template amount with your own pricing. |
Next steps | Carries the signature and fee summary, and explains what happens after acceptance to schedule the work. |
Payment | States the payment stages and due dates, then covers change requests, required client inputs, and the included revision limits. |
Timeline | Explains how dates get confirmed after discovery, what happens around third-party services, what gets handed over on launch, and the post-launch fix window and ownership. |
Who it is for
Web designers and developers quoting a fixed-scope website build that includes a CMS handover and functional flows like enquiries, payments, or bookings.
The proposal in full
Overview
You’ll have a website that does the job while you get on with yours: enquiries land in the right place, payments go through, bookings get recorded, and everyday updates stay in your hands.
You got in touch because the current setup has started to feel stitched together. When this is live, you’ll have a site you can update day to day, with a clear admin area and a handover you can actually use. This proposal covers the build, the timeline, and what it costs.
I keep the build simple on purpose. I write the scope first, then design what we’re building, then build it in small, testable pieces so nothing turns into a last‑week scramble. You’ll see progress every week, and you’ll have a single place to review, comment, and approve before anything goes live.
Who you are working with
I’m Aisha Tuffen, and I run Redcliff Studio as a one‑person build shop. I started in design, moved into full‑stack development, and ended up here because most small businesses do not need a clever stack. They need a site that loads fast, stays secure, and keeps working when nobody is watching it.
People hire me when they want a fixed price, a clear scope, and a handover they can use without a developer on speed dial. I document decisions as I go, I build with boring, well‑supported tools, and I leave you with admin screens and a CMS that match the way you actually update the site.
Recent projects
Here are a few recent builds that show the kind of problems I’m usually brought in to tidy up and automate.
Workshop bookings site
Replaced email back‑and‑forth with a bookings flow, calendar rules, and a simple admin view. The owner could add sessions, cap places, and see who paid without keeping a separate spreadsheet.
Service business enquiries rebuild
Designed a clearer service page structure and rebuilt the site with a proper enquiry form, routing, and confirmations. Enquiries stopped getting lost and the client could change copy and pricing safely.
Catalogue and payments setup
Built a small product catalogue with Stripe checkout and an order tracker. The client could add products, pause items, and refund from one place, with receipts and emails handled automatically.
“I was worried I’d be locked in, but the admin area is straightforward and the notes are clear. The site launched on schedule and I can make changes myself.”
Owner-manager, a small service business
Our approach
I run this like a steady handover. I’ll keep decisions visible, write things down in plain English, and build in a way that stays maintainable when the project is no longer fresh in anyone’s head.
1. Discovery and scope Week 1 I’ll confirm what the site needs to do, what it needs to integrate with, and what “done” means. I’ll turn that into a written scope you can approve, including pages, key user flows, and the limits that keep the price fixed. 2. Design and content fit Week 2 I’ll design the key pages around your content and the actions you need visitors to take. You’ll review the designs in one place and I’ll apply a set number of revision rounds, so we can make changes without dragging the schedule out. 3. Build and admin Weeks 3-5 I’ll build the front end and the back end together, so forms, payments, bookings, and the database all line up. I’ll also build the admin screens and CMS editing, so the things you’ll change later are the things that are easiest to change. 4. Launch and handover Week 6 I’ll run through testing, analytics, basic SEO setup, and a launch checklist. Once the site is live, I’ll hand over logins, written how‑to notes, and a short walkthrough so you know where everything is and what to do if something looks off.
Approved written scope
A plain-English description of what I’m building, including pages, key flows, integrations, and the edges of the job that keep the price fixed.
DESIGNS FOR KEY PAGES
Designs for the pages that do the work, sized for desktop and mobile, with two revision rounds included so you can refine without reopening the whole project.
BUILT WEBSITE AND CMS
A working site with editing set up for the parts you’ll change regularly, like pages, posts, products, services, or FAQs, depending on what the site needs to run.
Forms, payments, or bookings
The functional parts that make the site useful, such as enquiry routing, Stripe payments, or a bookings flow, built so you can see and manage what came in.
ADMIN SCREENS AND DATABASE
A database structure that matches the real data you need to store, plus admin screens that let you review, update, and export information without asking me.
HANDOVER PACK
Logins, setup notes, and a short guide to the day-to-day jobs: editing content, adding products or services, checking orders or bookings, and what to do when something fails.
Pricing
Pick the tier that matches how much your site needs to do on day one. Each option is fixed-price for the scope we agree in writing.
Priced items
Next steps
If the scope and price below feel right, signing is what turns this into a scheduled build with a clear start date.
1. Sign the proposal to confirm the scope and price. 2. Send over your content and any existing logins I need to reuse. 3. Book the discovery call so I can write the scope for approval.
Signature
Fee summary
Payment
I take 40% to book the work, 40% when you approve the designs, and 20% on launch. Invoices are due within 7 days, and I don’t schedule launch until the final invoice is paid.
Scope. I build what’s in the approved written scope. If you want to add or change anything, I’ll price it in writing before I do it. If you approve the change, the timeline and total price update with it.
Your input. I’ll need your content, access to your domain and any third-party accounts, and a single point of contact for decisions. When I ask for something, I’ll give you a date. Late inputs move the timeline.
Revisions. Design includes two rounds of changes across the key pages. Build includes one round of changes after you review the working site. Extra rounds are billed at £85 per hour, agreed before I start them.
Timeline
I’ll confirm dates after discovery, because that is where the scope and content shape the build. Once dates are agreed, I’ll keep you to short review windows so the work doesn’t stall in the middle.
Third party services. Anything I connect to your site, like Stripe, booking tools, email marketing, or other APIs, is supplied by that provider. If a provider has downtime, changes its API, or refuses access, I’ll show you options and costs.
Launch and after. On launch day I’ll deploy the site, run a basic smoke test, and hand over logins and the handover pack. If something breaks in the first 14 days because of my build, I’ll fix it at no cost.
Ownership. Once the final invoice is paid, you own the finished site and its content. I keep the right to reuse general ideas and non-identifying code patterns. I can show the work in my portfolio unless you ask me not to.
Questions about this proposal template
What should a web design proposal include?
A web design proposal usually includes the scope, how the work will run, the price, payment stages, a timeline outline, and what happens after launch. This one also covers revisions, third-party services, ownership, and what goes into the handover pack.
How do you write a scope for a website project?
A useful scope names the pages, key user flows, integrations, and the boundaries that keep the price fixed. This proposal includes an Approved written scope section that describes those items in plain English.
How do you avoid getting locked into a developer after a site launch?
Lock-in usually happens when admin tools and documentation don’t match the updates the business needs to make. This proposal spells out the CMS setup, the admin screens, and the handover pack so the client can see what they’ll control day to day.
How should website project payments be structured?
Website payments often split across booking the work, approving designs, and launching the site. This proposal uses 40% to book, 40% on design approval, and 20% on launch, with invoices due within 7 days and launch not scheduled until the final invoice is paid.
What happens if the client asks for changes mid-project?
Change requests should get priced in writing before the work starts, then the timeline and total update only after approval. This proposal ties the build to the approved written scope and explains how additions or changes get handled.
Who fixes the website if something breaks after launch?
A proposal should state what gets fixed and for how long, so support doesn’t turn into guesswork. This one says issues caused by the build get fixed at no cost in the first 14 days after launch.
Start free today
Your entire business, one login away
No credit card required. No contracts. Just the tools you need to run, grow, and automate your business with Super Work AI.
No credit card required
