What should a website development proposal include? A checklist before you sign

1. Your goals, in their words

The proposal should restate what the website is for: more enquiries, online sales, bookings, recruiting. If it doesn't mention your goals, the developer may not have understood them.

2. Scope: exactly what's included

• A list of pages or page templates.
• Every feature: forms, payments, booking, search, member areas, integrations.
• Languages, if more than one.
• Which devices and browsers it will be tested on.
• SEO setup: page titles, meta descriptions, sitemap, analytics, redirects from your old site.

3. What's explicitly not included

A good proposal lists exclusions: copywriting, photography, stock image licences, product data entry, translations, paid plugins, hosting fees. Exclusions aren't a bad sign; missing exclusions are, because you'll find out about them later.

4. The platform and why

WordPress, Shopify, a custom build or something else, with a sentence on why it suits your project, and what it will cost to run each year.

5. Design approach

Custom design or a theme? How many design concepts or revisions? Will you see designs before development starts?

6. Content responsibilities

Who writes the text, supplies photos and loads products or articles, and by when. Content delays are the most common reason launches slip, so the proposal should say what happens if content arrives late.

7. Timeline with milestones

• Start date and launch date or window.
• Milestones you'll see: designs approved, staging site ready, content loaded, testing, launch.
• What the developer needs from you at each milestone, and by when.

8. Price and payment schedule

• A fixed price or an estimate, clearly labelled as which.
• Payments tied to milestones you can see, not just dates.
• What changes cost if you add to the scope.
• Taxes stated clearly.

9. Revisions and change requests

How many rounds of changes are included at each stage, and how changes outside the scope are quoted and approved.

10. Ownership and accounts

This one matters most in the long run. The proposal should state that, on payment, you own the website, its code, designs and content, and that the domain, hosting and all accounts are in your company's name. If the developer uses licensed components (themes, plugins), it should say whose licence they're under.

11. Testing and launch

What gets tested before launch, who signs off, and how the launch itself is handled, including moving from an old site without breaking links.

12. Training and handover

How your team will learn to update the site, and what documentation and logins you'll receive.

13. Support after launch

• A warranty period for fixing bugs at no charge.
• Optional maintenance: updates, backups, security, small changes, and response times.

14. Communication

Who your contact is, how often you'll get updates, and through which channel.

15. The team

Who will actually do the work, and whether any part will be subcontracted.

How to use this checklist

Go through each proposal and mark every item as clear, vague or missing. Send the vague and missing items back as questions. A good developer will answer quickly and update the proposal. If several proposals look very different in price, the checklist usually shows why; see why two agencies quoted wildly different prices. And for the questions to ask before you even get to proposals, see how to hire a web developer.

A few proposal questions

Is a proposal the same as a contract? Not always. Some proposals become the contract when signed; others sit alongside separate terms. Make sure the scope and ownership terms are part of whatever you sign.

What if the developer won't put something in writing? Treat that as your answer. Anything important enough to discuss is important enough to write down.

How detailed should it be for a small site? Shorter, but the same items apply. A one-page proposal can still cover scope, price, timeline, ownership and support.