How to Write a Proposal for a Website Project

How should you scope pages, templates, and CMS in a website proposal?

List deliverables as quantities: up to twelve pages from agreed wireframes, three reusable templates, CMS training session, and migration of up to fifty blog posts. Name the stack—WordPress, Webflow, Shopify—and who provides hosting credentials.

Define what a page means: unique layout versus duplicate structure. Ambiguity here creates the classic can you add just one more page loop.

If discovery is required, sell a paid discovery phase that outputs sitemap and wireframes before build pricing locks.

Pair this with the web design proposal template, how to price a website project, and the proposal pricing guide. See Bidcraftr pricing when you are ready to send and track proposals professionally.

Who owns content, revisions, and approvals?

State who writes copy, who sources photography, and what happens if content is late. Example: launch date shifts one week for every five business days of delayed content after kickoff.

Include one consolidated feedback round per template after wireframe approval. Extra rounds are billable or purchased as a change order.

List client responsibilities: brand files, logins, legal approvals, and a single decision maker. Most delays are client content delays, not developer slowness.

What technical scope belongs in a website proposal?

Cover responsive breakpoints, browser support, performance targets at a high level, forms, analytics setup, SEO basics (titles, meta, sitemap), and accessibility standard you will meet—for example WCAG AA for key templates unless excluded.

Define QA: cross-device testing, form submissions, 404 handling, and staging review before launch. Name who performs UAT and for how many days.

Integrations—CRM, email platform, booking—should be line items with assumptions about API access and vendor fees.

How should you price and phase website projects?

Use deposit plus milestone payments: forty percent kickoff, thirty percent design approval, thirty percent launch. Tie payments to visible artifacts, not calendar dates alone.

Offer tiers: Launch (core pages), Grow (blog plus integrations), Scale (custom features). Anchor the recommended tier to their stated goals from discovery.

Include optional retainers for maintenance so launch does not end your revenue abruptly.

Should hosting, domain, and post-launch support be included?

State whether hosting and domain setup are included, client-managed, or billed separately. Say who configures DNS at launch and who owns billing after go-live.

Include a thirty-day bug-fix window for issues reproducible on supported browsers. Exclude content edits, new pages, and feature requests unless under a care plan.

Spell out training deliverable: recorded walkthrough or live session length. Clients respect boundaries when launch support is defined.

What timeline and phase structure should a website proposal include?

Phase one might cover discovery, wireframes, and design approval. Phase two covers development and content integration. Phase three is QA, launch, and training. Each phase should have dates, client responsibilities, and payment tied to acceptance.

Basic marketing sites often run four to eight weeks; custom builds run eight to sixteen weeks; ecommerce can run twelve to twenty-four weeks depending on catalog size.

A visual timeline table helps non-technical buyers see progress. Call out risks: missing API docs, legal review of copy, or committee approvals.

How do you handle change requests after the website proposal is signed?

Reference the signed scope table when new pages appear. Quote change orders in writing with timeline and fee delta before work starts.

Keep a simple log of out-of-scope requests so renewals and maintenance quotes stay honest.

Clients respect vendors who enforce scope calmly; they exploit vendors who say yes to everything without updating paperwork.

When stakeholders multiply after kickoff, pause and reconfirm decision makers in email so feedback does not fork into conflicting directions.

Screenshot the signed scope table in your project folder so every new request is compared against what was sold, not what someone wishes was sold.

What should you verify before you hit send?

Read the proposal on your phone. If the first screen does not show what you deliver, what it costs, and the single next step, rewrite the opening until it does.

Match every number to what you said on the call or in writing earlier. Pricing surprise is the fastest way to turn a warm lead into silence.

Set follow-up reminders for days three, seven, and fourteen before you move to the next task. Most wins need a second or third touch, not a perfect first draft.

Save this version as your master template when the deal closes. Reuse structure and tables so the next proposal ships in minutes, not hours.