A web design proposal should make it possible to answer one question before you pay: what exactly are you buying, and what will you own when the project is finished?
A page count, delivery date and total price are not enough.
Two designers can quote the same amount for “a 10-page business website” while offering completely different work. One may include content structure, mobile testing, analytics, form testing, redirects and handoff. The other may mean ten pages assembled from a template, with everything else charged later.
The proposal is where that ambiguity should disappear.
The short version: what a good website proposal should cover
Before paying a deposit, look for clear answers to these areas:
- the business goal and success criteria
- the exact scope and deliverables
- design and responsive behavior
- content responsibilities
- functionality and integrations
- SEO and migration responsibilities
- forms, analytics and measurement
- testing and acceptance criteria
- timeline, approvals and dependencies
- pricing, payment milestones and exclusions
- domain, hosting, source code and account ownership
- maintenance, warranty and handoff
The important word is clear. A proposal does not become good because it is long. It becomes useful when it reduces the number of expensive assumptions both sides are making.
1. Start with the business outcome, not the number of pages
A website is rarely being purchased because a company wants pages for their own sake.
A clinic may need more appointment requests. A hotel may want more direct bookings. A consultant may need qualified enquiries. A school may want parents to understand admissions and complete the next step without calling for basic information.
The proposal should connect the build to that outcome.
If the only project definition is “Home, About, Services, Gallery and Contact,” you know the sitemap but not whether the designer understands the job the website must perform.
A stronger proposal might define priority journeys such as:
- visitor lands on a service page and requests a consultation
- prospective parent finds admissions requirements and starts an application
- hotel guest compares rooms and reaches the booking engine
- customer discovers a product and completes checkout
That distinction matters because the user journey determines what needs to be designed, measured and tested.
2. Separate page count from unique design work
“10 pages” sounds precise but can still be misleading.
Ten pages built from three reusable templates are a different design problem from ten pages with ten distinct layouts and interactions.
Ask the proposal to clarify:
- which pages or page types are included
- which layouts are unique
- whether inner pages receive intentional design or simply inherit a generic template
- whether mobile and tablet behavior is designed and tested
- whether reusable components are part of the system
- how many revision rounds are included
This helps you compare proposals on actual work rather than headline page count.
3. Make content responsibility explicit
Content is one of the easiest places for a website project to stall.
Who writes the copy? Who supplies photographs? Who compresses and prepares images? Who uploads products, team members, rooms, services or existing articles? Who approves the final text?
If the client is responsible, the proposal should say so. If the designer is responsible, it should define how much content work is included.
Also distinguish content entry from copywriting. Moving text you supplied into a CMS is not the same service as researching, structuring and writing persuasive website copy.
For an existing website, clarify whether content migration is included and what happens to old URLs. That becomes especially important when the old site already receives search traffic.
4. Replace “SEO-friendly” with concrete deliverables
“SEO-friendly website” is too vague to evaluate.
Ask what it means in the project.
Useful development-stage deliverables can include:
- sensible crawlable URL structure
- page titles and meta-description controls
- canonical handling where appropriate
- XML sitemap and robots configuration
- structured data where it genuinely applies
- image alt-text/content fields
- redirect mapping when existing URLs change
- Search Console and analytics setup
- performance checks
Google’s Search documentation explicitly recommends permanent server-side redirects such as 301 or 308 when a page URL changes and you want search results to point to the new location. That is why a redesign that changes indexed URLs needs a migration plan, not merely a new visual design.
Source: https://developers.google.com/search/docs/crawling-indexing/301-redirects
If you are replacing an existing site, use my website migration SEO checklist alongside the proposal review.
Ongoing keyword research, link building, content production and ranking work are separate services unless the proposal explicitly includes them. Do not assume “SEO-friendly” means ongoing SEO.
5. Define functionality by behavior, not labels
A proposal may say “contact form,” “booking,” “payment integration” or “customer portal.” Those labels hide a lot of product decisions.
For a contact form, for example, ask:
- which fields are required?
- where are submissions delivered or stored?
- what confirmation does the visitor receive?
- who receives notifications?
- what happens if email delivery fails?
- is spam protection included?
- is successful submission measured as a conversion?
Google’s web.dev guidance recommends testing forms on different devices, browsers and input methods, including validation, error handling and submission behavior.
Source: https://web.dev/learn/forms/test-forms
The same principle applies to booking, payments and integrations. Define the important states, not just the happy-path button.
6. Ask how success will be measured after launch
If the website is supposed to generate enquiries, bookings or sales, the proposal should say whether measurement is included.
That might mean analytics installation, conversion events and Search Console verification. It might also mean documenting which actions count as a lead.
A beautiful website with an unmeasured form leaves you guessing whether the redesign improved anything.
For lead-generation websites, I usually think about the full chain: traffic → relevant page → action → successful submission → business receives the lead.
If your existing website already gets visitors but produces few enquiries, read Website Not Generating Leads? Fix It or Redesign It? before assuming a complete rebuild is necessary.
7. Put mobile and accessibility into the acceptance criteria
“Responsive” should not mean somebody shrank the browser window once.
Important journeys should be tested on realistic small screens: navigation, forms, buttons, booking or checkout transitions, long content, tables and any sticky controls.
Accessibility should also be treated as an implementation concern rather than decorative polish. The W3C’s Web Content Accessibility Guidelines cover principles including perceivable content, keyboard operability, understandable interfaces and robust markup.
Source: https://www.w3.org/WAI/standards-guidelines/wcag/
A proposal does not need to promise legal compliance it cannot substantiate. It should, however, state the accessibility standard or practical checks the project includes when accessibility is part of the scope.
8. Confirm who owns the domain and critical accounts
This is one of the questions I would never leave until handoff.
Your website can look completely finished while the business remains dependent on somebody else’s registrar login, hosting account, analytics property or deployment account.
The proposal should identify who owns or controls:
- domain registrar account
- DNS
- hosting or cloud account
- CMS/admin account
- analytics and Search Console
- source-code repository where relevant
- payment-provider account
- email or form-delivery service
- licensed themes, plugins or fonts
ICANN notes that the registered name holder is the person or entity holding the rights to a registered domain name. In practical terms, do not treat domain control as a minor technical detail.
Source: https://www.icann.org/resources/pages/registrant-2013-09-17-en
For business-critical services, I prefer the business to own the account and grant the designer appropriate access rather than discover after launch that the company cannot independently control its own infrastructure.
9. Define what “handoff” actually means
A finished project should not become a scavenger hunt.
Depending on the stack, handoff may include:
- admin credentials and role setup
- source-code/repository access
- design files
- deployment access
- domain/DNS access
- third-party service inventory
- documentation for common edits
- a short training session
- backup/recovery instructions
- license information
- known limitations or future-work notes
If the website has a CMS, ask what your team will actually be able to edit without calling the developer.
“Editable website” is not specific enough. Can you add a service? Change a price? Add a team member? Publish an article? Replace a hero image? Update a room? Change contact details?
Those are operational requirements, not just technical features.
10. Understand maintenance before you confuse it with warranty
A short post-launch warranty for defects is not the same thing as ongoing maintenance.
The proposal should distinguish:
- bugs caused by the delivered work
- new feature requests
- content updates
- CMS/plugin updates
- hosting support
- monitoring and backups
- third-party failures
- response times
- included support hours
If ongoing support is offered, ask what triggers an extra charge and whether unused hours roll over.
For Nigerian businesses comparing retainers, my guide to website maintenance cost in Nigeria explains why the workload and responsibility matter more than a single monthly price.
11. Look for exclusions, assumptions and dependencies
The most useful section of a proposal can be the part explaining what is not included.
Examples include:
- paid stock photography
- premium plugins
- third-party SaaS fees
- copywriting
- product data entry
- translations
- complex integrations
- legal/privacy copy
- ongoing SEO
- paid advertising
- hosting
- maintenance after the warranty period
Clear exclusions are not a red flag. Hidden exclusions are.
Also look for dependencies: “client must supply final copy before development,” “payment-provider approval is the client’s responsibility,” or “timeline pauses when approvals exceed three business days.” These protect both sides from a schedule that looks fixed while key inputs remain undefined.
12. Define acceptance before the final invoice
How does everybody know the website is finished?
A proposal should establish an acceptance process rather than leaving “done” to opinion.
For a typical business website, acceptance might include:
- agreed pages and functionality delivered
- priority mobile journeys tested
- forms successfully delivered and confirmed
- broken links checked
- agreed analytics events firing
- redirects verified for migrated URLs
- client content approval completed
- agreed browser/device checks completed
- ownership/access transferred
- critical launch defects resolved
This does not mean every project needs enterprise paperwork. It means the final payment should correspond to an observable delivery state.
A simple way to compare two website proposals
Do not compare only the totals. Create a short comparison sheet and mark each important item as:
included / excluded / unclear / additional cost
Compare business discovery, unique templates, copywriting, content entry, integrations, SEO migration, forms, analytics, mobile testing, accessibility, hosting, licenses, maintenance, ownership and handoff.
The “unclear” column is often more revealing than the price column.
If one proposal costs less because five responsibilities have simply been left undefined, it is not necessarily the cheaper project.
Before you pay the deposit
You should be able to explain the project in plain English:
what problem the website should solve, what will be delivered, what you must provide, how the result will be tested, what is excluded, what you will own, and what happens after launch.
If you cannot do that after reading the proposal, ask for clarification before paying.
I also recommend using these questions to ask a web designer before hiring when evaluating the person behind the proposal.
If you want a website engagement scoped around the business outcome rather than a vague page package, see my web design service or contact me with the result you need the website to produce.
