A website proposal should do more than name a price and promise a modern design. It should explain what the website must accomplish, what will be delivered, who owns the accounts and assets, how the work will be tested, what happens after launch, and which responsibilities remain with the business.
This matters whether the provider is a freelancer, agency, consultant, software platform, or AI-assisted website service. A low initial price can become expensive when essential work is excluded. A higher price is not automatically better if the scope remains vague.
Use these questions to compare proposals on the same basis.
The proposal should identify the primary business job of the website. Examples include generating estimate requests, booking appointments, supporting local search, selling products, recruiting employees, educating customers, or reducing repetitive service questions.
“Build a five-page website” describes output, not outcome. Ask how the recommended pages and features support the customer’s decision and the business process that follows.
Request a specific list of pages, templates, forms, integrations, content, images, and technical setup. Clarify whether legal or policy pages, thank-you pages, search pages, error pages, and mobile layouts are included.
If the scope uses phrases such as “up to five pages,” ask what counts as a page and how additional work is priced.
Clarify who researches, writes, edits, verifies, and approves the copy. If AI is used, ask who checks business facts, claims, locations, prices, policies, credentials, and source attribution.
The business should have final approval. The proposal should also explain how many review rounds are included and what happens when information arrives late.
Ask whether the project uses original photography, customer-supplied images, licensed stock, AI-generated images, or a combination.
Confirm who owns the final files, which licenses are transferable, whether attribution is required, and whether editable design files are included. Image creation should not be treated as an invisible line item.
Understand where the site will run, why the platform fits the project, and which limitations matter. Ask about export options, hosting, bandwidth, storage, user accounts, ecommerce limits, forms, integrations, and required subscriptions.
The correct platform depends on the website’s job. A simple information site and a complex ecommerce or membership system have different needs.
The proposal should state which accounts will be created, whose business information will be used, and what administrator access the client receives.
The business should control the domain and critical recovery methods. Use the complete website ownership checklist before the project begins.
Ask what happens if the relationship ends or the platform no longer fits. Can pages, media, products, orders, customer records, and other data be exported? Which design or platform components cannot be transferred?
An exit plan does not mean the business expects the relationship to fail. It is ordinary continuity planning.
The provider should test more than whether a form appears on the page. The test should confirm validation, success messages, customer confirmations, staff notifications, CRM delivery, automation, and mobile use.
Ask how booking, payment, chat, download, click-to-call, and email actions will be tested. Define what evidence is required for acceptance.
Ask which accessibility practices are included in design, content, development, and testing. The response should discuss meaningful work such as keyboard access, visible focus, contrast, alternative text, labels, headings, error messages, zoom, captions, and human testing.
Be cautious with proposals that reduce accessibility to installing a widget or running one automated scan. Our article on automated accessibility tools explains why that is incomplete.
No provider should promise universal or permanent compliance without understanding the site, applicable requirements, and ongoing changes.
Ask about multifactor authentication, user roles, software updates, HTTPS, spam protection, backups, monitoring, payment responsibilities, and incident escalation.
Security depends on the platform and risk. The provider should explain what it handles, what the platform handles, and what remains the client’s responsibility.
The proposal should explain what is backed up, how often, where backups are stored, how long they are retained, and who can restore them.
Ask whether restoration is included in the maintenance agreement and when the process was last tested. A backup feature and a recovery service are not necessarily the same deliverable.
Clarify whether the work includes page titles, descriptions, heading structure, redirects, canonical URLs, sitemap setup, Search Console verification, indexing review, structured data, internal links, and local business consistency.
SEO should not be sold as a guaranteed ranking. Google explicitly warns that no one can guarantee a number-one ranking. A responsible provider should explain the work, expected time frame, measurement, and uncertainty.
Use the technical SEO checklist to compare the proposed launch work.
Decide which actions matter before launch. Examples include calls, forms, bookings, purchases, applications, and key downloads.
Ask which analytics and tag accounts will be used, who owns them, what events will be configured, and how consent or privacy choices affect measurement. A dashboard is not useful if no one knows what decisions it supports.
Ask which real devices, screen sizes, and browsers are included. Builder previews are useful but do not replace opening the site on actual phones and completing customer tasks.
The acceptance checklist should include navigation, forms, tap targets, pop-ups, consent tools, checkout, booking, text zoom, and layout changes.
A proposal should identify milestones, client dependencies, review windows, content deadlines, launch conditions, and the effect of delayed approvals.
Ask which work can happen in parallel and which items block the next stage. A launch date without a content, testing, and approval schedule is only an estimate.
Separate the initial project price from ongoing costs. Ask about:
Use the real cost of an AI website builder to create a full ownership budget.
Ask how long post-launch support lasts, what qualifies as a defect, how requests are submitted, expected response times, and which work is billed separately.
The small-business website maintenance plan explains the recurring tasks that should be assigned even when the platform handles technical updates.
The handoff should include administrator access, account inventory, billing details, source files, licenses, approved content, form and integration map, analytics access, backup instructions, maintenance schedule, training, and known issues.
Define handoff before the project starts. Otherwise, the business may discover at the end that essential files, accounts, or training require additional payment.
Create a comparison table using the same categories for every provider:
Score only what is written and explained. Do not fill gaps with assumptions.
A proposal cannot remove every uncertainty, but it should make the project understandable. The owner should know what is being purchased, which decisions remain, what the business controls, and how the website will be supported after launch.
Google recommends interviewing potential SEO providers, checking prior work and references, asking how results will be measured, and requiring explanations for recommended changes. Those practices are useful when evaluating a complete website provider too.
For an independent second opinion, explore our services, review case studies and client reviews, or contact David.
What business outcome is the website designed to support? A proposal that describes output (“five pages”) without explaining the customer decision and business process it supports is not yet a complete plan.
No. Google warns that no one can guarantee a number-one ranking, and no provider should promise universal compliance without understanding the site and ongoing changes. Guarantees like these are a red flag.
Administrator access, an account inventory, billing details, source files, licenses, approved content, a form and integration map, analytics access, backup instructions, a maintenance schedule, training, and known issues.
