Web Developer Proposal Template (Free, Copy-Ready)

A full proposal for a website or small web app build, written so you can copy it, replace the brackets and send it. Below the template: how to write the parts clients actually read, and the scope lines that prevent arguments later.

Updated September 30, 2026

The template

Replace everything in [brackets]. Delete any line that doesn't apply rather than leaving it vague. A shorter proposal that's specific beats a longer one that hedges.

PROPOSAL: [Project name]
Prepared for: [Client name], [Company]
Prepared by: [Your name], [Your business]
Date: [Date]   Valid until: [Date + 30 days]

1. SUMMARY
[Company] needs [a new marketing site / a rebuild of the current site / a small web app for X] so that [business outcome, e.g. "customers can book appointments online instead of calling"]. I'll build it on [stack or platform], focused on [the one goal that matters most], and hand over a site your team can update without a developer.

2. SCOPE: WHAT'S INCLUDED
- [Number] page templates: [Home, About, Services, Service detail, Contact, Blog index, Blog post]
- Responsive layouts for mobile, tablet and desktop
- [CMS, e.g. WordPress / Webflow / a headless CMS] set up so your team can edit [pages, blog posts, team members, FAQs]
- Contact form delivering to [email address], with spam protection
- On-page SEO basics: page titles, meta descriptions, XML sitemap, redirects from old URLs
- [Analytics tool] installed and verified
- Launch on your domain and hosting, including SSL
- [2] rounds of revisions at each stage (design, build)
- A 30-minute handover call and a short written editing guide

3. NOT INCLUDED
- Copywriting and photography. You'll supply final text and images by [date].
- Hosting fees, domain renewals, and paid themes, plugins or licenses
- Features not listed in section 2, such as online payments, user accounts or third-party integrations. Happy to quote these separately.
- Changes after the [30]-day post-launch support window (see Ongoing support below)

4. TIMELINE
Week 1: Kickoff call; sitemap and content plan agreed
Weeks 2-3: Designs for [key pages]; your feedback within [3] business days of each review
Weeks 4-5: Build and CMS setup on a private staging link
Week 6: Cross-browser and device testing, your final review, launch

This timeline assumes content and feedback arrive on the dates above. If either side is late, the launch date moves by the same amount.

5. INVESTMENT
Option A: [Name, e.g. "Launch"]: [one-line scope summary] ..... [price]
Option B: [Name, e.g. "Launch + Blog"]: [Option A plus the extras] ..... [price]

Payment: [50]% to start, [50]% at launch. Invoices are due within [14] days.
Ongoing support (optional): [price] per month for updates, backups and up to [N] hours of small changes.

6. WHAT I NEED FROM YOU
- One point of contact who can approve work
- Final copy and images by [date]
- Access to your domain registrar, hosting and any existing site
- Feedback within [3] business days at each review point

7. TERMS
- Revisions: [2] rounds per stage are included. Extra rounds are billed at [hourly rate].
- Scope changes: anything not in section 2 is quoted in writing before work starts.
- Ownership: the finished site and its content are yours once the final invoice is paid. I may reuse general code patterns and show the project in my portfolio unless you ask me not to.
- Bug fixes: I'll fix defects reported within [30] days of launch at no charge.
- Cancellation: either side can end the project with written notice. You pay for work completed up to that point.

8. NEXT STEPS
Reply to accept this proposal and I'll send the first invoice and a kickoff time. I can start on [start date] if we confirm by [decision date].

Write the summary about their problem, not you

The summary is often the first thing a client reads, and sometimes the only part a decision-maker reads. It should prove you understood the problem well enough to explain it back. Your experience belongs further down, next to the work it's relevant to.

We are a passionate team of developers with 10 years of experience building beautiful, modern websites. We would love to work with you on your new website.

Right now, every booking at Harbor Physio comes in by phone, and your front desk told us they miss calls at peak times. This project replaces the current site with one where patients can see open slots and book directly, synced to your existing calendar, so the phone stops being the only way in.

The second version names the client, the current problem, who noticed it, and what changes after launch. None of that needs a claim about how good you are.

Fixed price, options, or hourly?

For a defined build, a fixed price is usually easiest for the client to approve, since they can compare it against a budget. Hourly suits work you can't scope yet, like debugging an unfamiliar codebase or open-ended maintenance. If you quote hourly, give an estimated range and say what happens when you approach the top of it.

Two or three options often work better than one number, because the client's question changes from "yes or no?" to "which one?". Keep the options genuinely different in scope, not the same work at three prices.

Example numbers, not market rates: Option A "Launch" (5 page templates, CMS, contact form) at $4,000, and Option B "Launch + Blog" (Option A plus blog templates, category pages and moving up to 30 existing posts) at $5,500. The gap between them is the extra days of work priced at the same day rate. Set your own numbers from your time, costs and the value to the client.

Scope lines that prevent arguments later

A lot of web project disputes come down to a word both sides read differently. These are the ones worth pinning down in writing:

• Pages: count templates, not pages. "6 templates" is clear; "a 6-page site" isn't once the client adds 20 blog posts.
• Content: say who writes the copy and supplies images, and by when. Late content is one of the usual reasons launches slip.
• Browsers and devices: name what you test on (for example, the current versions of Chrome, Safari, Firefox and Edge, on iOS and Android).
• Integrations: list each one by name. "Integrates with our tools" can mean anything.
• Revisions: rounds per stage, and what counts as a round (one consolidated list of feedback, not a stream of messages).
• Launch: who owns the hosting account and domain, and who pays for them.
• After launch: how long you fix bugs for free, and what "bug" means (something that doesn't work as agreed, not a new idea).

Mistakes that make web proposals harder to accept

• Listing your tech stack as the selling point. Clients buy the outcome; mention the stack where it affects them, such as who can edit the site.
• Leaving out what's not included. If it isn't written down, the client will assume it's in.
• A timeline with no dependencies. Dates only hold if content and feedback arrive on time, so say so.
• No expiry date. A proposal without a "valid until" date can be accepted months later at the old price.
• Ending without a next step. Tell them exactly how to say yes, and when you could start.

Checklist before you send

• The summary mentions the client by name and their specific problem
• Every deliverable is countable or checkable
• There's a "Not included" section
• The timeline says what you need from them, and by when
• Payment terms are stated (deposit, milestones, due dates)
• Ownership and post-launch support are covered
• There's a valid-until date and a clear way to accept