Website Proposal Templates

A website proposal is a scope document wearing a sales document’s clothes. Almost every web project that ends badly does so for one of two reasons — nobody agreed what “finished” meant, or the client never sent the content — and both are decided in the proposal rather than in the build. These three free website proposal templates in Microsoft Word give you the structure. The sections below cover the four clauses that decide whether the project ends in a launch or an argument.

Define what “done” means

The commonest costing mistake in web work is quoting for pages. Pages are nearly free once the design exists; what costs money is the number of distinct layouts. A forty-page site built from four templates is a smaller job than a six-page site where every page is bespoke, and a proposal priced per page gets this exactly backwards.

So describe the deliverable in terms the client can count and you can defend:

The last row is the one that earns its place. “Revisions until you are happy” is an unlimited commitment at a fixed price, and it is how fixed-price web projects quietly become loss-making. Two rounds at the design stage and two at build, with anything further charged at a stated hourly rate, is a normal and defensible arrangement — and it is kinder to the client too, because it tells them that feedback has a cost and should be gathered rather than dripped.

Just as useful is an explicit not included list. Copywriting, photography, logo design, SEO work, ongoing maintenance, content migration from the old site, training beyond one session: name whichever of these you are not doing. A proposal that only lists inclusions invites the client to assume everything unmentioned is covered. If the project is large enough to have phases, the sequencing belongs in a project plan attached to the proposal rather than buried in a paragraph.

Free website proposal templates

Each file is a Microsoft Word document. Edit the scope and pricing sections properly before sending — the boilerplate around them matters far less than the two or three paragraphs that define the work.

Website Proposal Template 01Download

Website Proposal Template 02Download

Website Proposal Template 03Download

Say who supplies the content, and what happens if it is late

Ask anyone who builds websites what delays projects and the answer is not technical. It is waiting for copy, logos and photographs from the client — and because the delay is the client’s, it rarely feels to them like a delay at all.

A proposal fixes this with three sentences. State what the client is providing and in what form. Give a date by which it is needed, tied to a milestone rather than to a vague “early in the project”. And say what happens if it does not arrive: the schedule moves by at least the length of the delay, the slot is reallocated, and the project is re-scheduled rather than compressed. That last clause is the one that protects both sides, because the alternative — absorbing a three-week content delay into a fixed launch date — means the quality drops and everyone blames the developer. When a content deadline does slip, confirm the new dates in writing the same week rather than absorbing it silently — a short dated memo stating what was outstanding and what the revised milestone is costs nothing and settles the question of whose delay it was.

Two practical additions. Offer placeholder content explicitly as an option, priced, so the client can choose between waiting and paying for copywriting. And if you are migrating an existing site, say how many pages of content are included in the migration and what happens beyond that number, because “we will move your existing content across” is an uncapped promise about a website you have not finished reading.

Name an accessibility conformance target

This is the clause most website proposals omit entirely, and it has moved from good practice to a legal question.

The relevant standard is the Web Content Accessibility Guidelines. WCAG 2.2 became a W3C Recommendation on 5 October 2023, adding nine success criteria to WCAG 2.1; WCAG 2.0 dates from December 2008 and became ISO/IEC 40500 in 2012. Each has three conformance levels, A, AA and AAA, and AA is the level the law generally asks for — the European Accessibility Act, the EU public sector directive, the UK public sector rules and the US Department of Justice’s Title II rule all specify WCAG 2.1 Level AA. Worth noting in passing that WCAG 3.0 is still a draft: no part of it is an official recommendation, so anyone promising it in a proposal is promising something that does not yet exist.

The European Accessibility Act matters most for commercial work because it reaches private businesses rather than only public bodies. Directive (EU) 2019/882 became enforceable on 28 June 2025, covering e-commerce, online banking, transport ticketing, telecoms, audiovisual media and e-books — and it applies to non-EU companies serving EU consumers, so a British or American business selling into the EU is in scope. Services already on the market before that date have until 28 June 2030. There is a microenterprise exemption, but it is narrow: fewer than ten employees and annual turnover below two million euros. Any SME above that threshold is expected to comply. Penalties are set nationally and are not trivial — Germany, for example, provides for fines up to one hundred thousand euros per violation — and enforcement can extend to ordering a service suspended.

There is one subtlety worth putting in writing, because it is exactly the sort of thing that causes a dispute later. The Act works through EN 301 549, the harmonised European standard produced by CEN, CENELEC and ETSI, and the version the Act points to incorporates WCAG 2.1 AA — not 2.2, even though 2.2 is the current W3C Recommendation and a later version of EN 301 549 includes it in full. So “we will build to the latest accessibility standard” and “we will meet your legal obligation” are not the same promise. Name the version and the level: WCAG 2.1 Level AA, or 2.2 AA if the client wants to be ahead of the harmonised standard.

For the proposal itself, three lines are enough. State the target version and level. State what testing is included — automated checks catch a minority of issues, so say whether manual keyboard and screen-reader testing is in scope. And state what is excluded, particularly third-party embeds and client-added content after launch, because you cannot warrant the accessibility of a video the client uploads next year.

Ownership, licences and what actually transfers

Clients generally assume they will own everything. Developers generally assume they keep their frameworks. Both are reasonable, and a proposal that does not address it leaves the question to be settled at the worst moment, which is final payment.

Third-party costs deserve their own line in the pricing rather than being folded into a total, because they recur and the client will meet them again next year whether or not you are still involved. Hosting, the domain, SSL where it is not included, plugin and theme licences, fonts, stock images, an email service: list them, say which are one-off and which annual, and say whose card they sit on. A proposal is also where to be clear that these are passed through at cost rather than marked up, if that is your practice. Once the proposal is accepted, those terms should carry across into the service agreement rather than being restated loosely, since the agreement is the document that governs if anything goes wrong.

Pricing, milestones and getting paid

Three decisions, and the proposal should settle all of them.

Fixed price or hourly. Fixed price suits work you can specify tightly, which is why the scope section above matters so much — a fixed price on a vague scope is a bet you will lose. Hourly suits discovery work and ongoing development, and clients dislike it mainly because it is open-ended, which a cap or a stated estimate with a variance range addresses.

The payment schedule. A deposit before work starts, instalments at named milestones, and a final payment at launch is the usual shape. Tie each instalment to a deliverable the client can see rather than to a date, so the schedule survives a delay on either side.

What happens after launch. Say where the project stops. A short warranty period for fixing defects — thirty days is common — is different from maintenance, and bundling them means you are still doing free work six months later. Offer maintenance separately and price it, even if the client declines; it is much harder to introduce afterwards.

Finally, keep the proposal shorter than you think. The impulse is to demonstrate thoroughness with forty pages, but the client reads the scope, the price and the timeline, and skims everything else. If you are putting proposals into a competitive process against several agencies, the economics of how many you write and how often you win are worth understanding separately — the bid proposal page works through that arithmetic.

Questions about website proposals