Web Development Proposal Template
Most web development proposals lose the job in the scope section, not the price section. This is the structure we use — nine sections, a worked pricing breakdown, and the one clause that has saved more projects than any other.
Copy it, cut what does not apply, and send it. If you want the structure pre-built with pricing tables and e-signature, ProposalBuild does that on the free plan — but the template works fine in a Google Doc.
The nine sections
Client name, project name, your name, the date, and an expiry date. The expiry is the part most people skip. A proposal without one stays 'under consideration' forever.
Two or three sentences describing what they told you, using their vocabulary. If they said 'our booking page loses people', do not translate it into 'conversion funnel optimisation'. This is the section that makes a client feel understood, and it costs you nothing.
Bullet every deliverable in concrete nouns: number of page templates, number of forms, which integrations, which CMS. "Responsive design" is not a deliverable. "Five page templates, each at three breakpoints" is.
The most valuable section in the document. Content writing, photography, ongoing hosting, third-party licence fees, SEO migration, training beyond one session — name whatever you are not doing. Every scope dispute traces back to an assumption the proposal never contradicted.
Your stack and why it fits their constraint, not why you like it. Two short paragraphs. Clients rarely read this closely, but its absence reads as inexperience, and technical evaluators check it first.
Phases with dates, and — critically — what you need from them by when. "Content due 12 March" in the proposal is the thing you point at in week six when content still has not arrived.
The price, broken into phases. See the worked example below. Put this on page two or three, never page nine.
The conditions your price depends on: existing brand assets are usable, one round of consolidated feedback per phase, staging access provided within five days. If an assumption breaks, this section is why the price changes.
One instruction. "Sign below and we start Monday." Not "let me know your thoughts" — that invites a delay, not a decision.
A worked pricing breakdown
Clients do not reject a number; they reject a number they cannot explain to whoever signs the cheque. A single “Website: $12,000” line gives them nothing to defend. The same total, itemised, is a document they can forward.
Here is a marketing-site rebuild priced at a $95/hour rate. The numbers are an illustration of the shape of a breakdown — your rate and hours will differ.
| Phase | Hours | Total |
|---|---|---|
| Discovery & information architecture | 8 | $760 |
| Design — 5 page templates | 30 | $2,850 |
| Front-end build | 45 | $4,275 |
| CMS integration & content migration | 20 | $1,900 |
| QA, accessibility & cross-browser | 10 | $950 |
| Launch & handover session | 6 | $570 |
| Subtotal | 119 | $11,305 |
| Contingency (10%) | — | $1,131 |
| Total | — | $12,436 |
Two things worth stealing from that table. The contingency line is visible, not buried in the hourly rates — clients accept a named 10% far more readily than they accept discovering it later. And the handover session is priced, not free. Anything you give away for free gets treated as free next time.
Tie payments to milestones, not to dates
A payment schedule of “50% upfront, 50% on completion” is how developers end up funding a client’s indecision. “Completion” is a date you do not control, because it depends on their content, their feedback, and their legal review.
Tie the money to events you control instead: 30% on signature, 30% on design approval, 30% on staging handover, 10% on launch. If the client sits on staging for two months, you have already been paid 90%. Same total, radically different cash flow.
The exclusions clause
If you take one thing from this page, take section 04. Write down what you are not doing, in plain language, in the proposal itself.
The reason is not legal, it is psychological. A client who assumed you were writing the copy is not being difficult — they genuinely believed it, because nothing told them otherwise. By the time the disagreement surfaces you are mid-build, the relationship is warm, and you will probably eat the work rather than fight about it. The exclusions section moves that conversation to week zero, when it costs nothing and you still have leverage.
Then follow up on evidence
Sending the proposal is not the last step. The gap between “sent” and “signed” is where most freelance revenue quietly dies, usually because the follow-up is a guess: you email after a week, apologetically, with nothing to say.
Knowing the proposal was opened three times and that someone spent real time on the pricing page changes that email completely. That is the specific reason we built engagement tracking into ProposalBuild — see proposal software for web development for how that works on a dev project, or read how to write a web development proposal for the process that comes before the template.