Website Development Proposal: What Should Be Included Before You Sign?

Deliverables you can count and name

"A modern, responsive website" is not a deliverable. A deliverable is something you can point to on delivery day. Look for a page or template list, such as home, service pages, a blog template, a contact page and a legal-pages template. Ask how many unique designs are included, since ten pages might use three layouts or ten. Check whether the proposal covers the CMS or admin setup, forms and where their submissions go, analytics installation, basic on-page SEO fields and redirects.

Also check which stage each item belongs to. Design files, a staging site and the live site are separate outputs, and a good proposal names all three. If you expect training for your team or a short handover document, those should appear as line items too.

Acceptance criteria: how "done" gets decided

Most disputes happen because nobody defined completion. A useful website proposal checklist includes a section on acceptance, covering who tests, against what, and for how long. Reasonable criteria are measurable. For example, pages render correctly on a stated list of browsers and screen widths, forms deliver to a named inbox, and agreed pages pass an agreed set of performance and accessibility checks using named tools.

Ask these commercial questions:

• Who signs off each stage, and by what method (email, ticket, signed form)?
• How many working days do you have to review, and what happens if you are late?
• How are defects separated from new requests? A defect is something that does not meet the written scope. A new request is something the scope never mentioned.
• Is there a defined bug-fix period after launch, and what does it cover?

Be wary of criteria such as "to the client's satisfaction" or "in line with best practice". Both sound fair but cannot be tested, and they tend to favour whoever holds more leverage at the time.

Exclusions and assumptions deserve equal attention

The exclusions list often says more about the real project than the scope does. Common gaps include content writing, image sourcing or photography, copy editing, data migration from an old site, third-party integrations, translation, and ongoing hosting or maintenance. None of these is wrong to exclude, but each one has to be done by someone, and if it is not the vendor, it falls on you.

Assumptions matter just as much. A proposal might assume that you supply final content by a set date, that one stakeholder consolidates feedback, or that an existing API is documented and working. When an assumption fails, the price or timeline usually moves. Read the assumptions and ask yourself honestly whether you can meet each one.

Costs outside the build should be separated clearly: applicable taxes (confirmed separately), domain and hosting, premium plugins or software licences, content creation, migration effort and post-launch care. A single bundled figure makes it hard to compare two proposals.

Payment milestones tied to evidence

Payment schedules work best when each instalment follows something you can verify: a signed-off design, a working staging site, completed testing, launch. Paying only by calendar date, regardless of progress, removes your ability to pause if things go off track. Paying everything at the end, on the other hand, is often unworkable for the vendor, so expect an advance to start the work.

Ask what the advance covers and whether it is refundable if the project is cancelled, and how the vendor treats work completed up to that point. Also ask what happens to the final payment if you delay sign-off, and whether the vendor holds back any files or access until payment clears. These are commercial terms to settle before signing, not afterwards.

Change control without surprises

Every project changes. What matters is whether the proposal says how. A workable change process has four steps: the request is written down, the vendor assesses its effect on cost and timeline, you approve or decline in writing, and only then does work start. Check how changes are priced, such as an hourly rate stated in the proposal or a fixed quote per change, and whether small tweaks have an allowance. Also ask how many design revision rounds are included, because "unlimited revisions" rarely survives a long project in practice.

A hypothetical budget to test any proposal

Below is an illustrative example of how a scoped quote should be possible to trace. It describes an invented small business website and is not a real client case.

All figures in the table, including recurring expenses, are hypothetical assumptions for arithmetic only. They are not quotes, market averages or vendor fees. Hosting, domain, taxes and ongoing care are excluded, and the table has no recurring line.

The check is simple: 180 hours at the assumed rate gives the total. In a real proposal, ask for this same traceability. If a vendor will not explain how a figure was built, you cannot judge whether a later change request is priced consistently. Then ask which milestones the five lines map to, and which exclusions would add effort, such as writing the copy or migrating a large archive of old pages.

Ownership, access and handover

Finally, ask who will own the design files, source code and content on completion, and when ownership passes. Ask whether you will hold the admin credentials, hosting account and domain registration in your own name. Check how third-party licences are handled, and what documentation you receive. Intellectual property and liability clauses are legal matters, so use a professional reviewer there. As a business reader, your job is to make sure the proposal raises the topics and does not leave them silent.

If the site handles sector-specific content such as health, finance or legal information, have the relevant professional review that content separately, since a development proposal does not cover it.