Jump to a section +
A proposal is useful when it makes the offer comparable and the project discussable. It is not the same thing as a portfolio, a price sheet, or a contract. A portfolio shows examples; a proposal describes a planned engagement; a contract creates the binding agreement and should be reviewed by qualified counsel when the stakes require it. The proposal should still be detailed enough that you can find a missing responsibility before work begins. This guide belongs with the other hiring and project-planning resources for preparing a safer website purchase.
Begin with the result, not a list of activities
The opening should identify the business problem, intended audience, desired visitor action, and the evidence that will be used to judge progress. “Design and build a new website” describes an activity. “Help commercial property owners understand three services and request a qualified site assessment” gives the team a basis for content, navigation, forms, and measurement. It still does not promise sales or rankings, because those outcomes depend on traffic, offer, follow-up, market conditions, and other factors outside the build.
The 12-part proposal anatomy
Read the offer in this order
1. Project context and objective
Names the problem, audience, current state, desired actions, constraints, and how the website supports the business. Correct misunderstandings here before debating features.
2. Scope boundaries
Defines which site, language, brand, business unit, location, platform, and project phase the offer covers. It should distinguish a redesign from a rebrand, marketing campaign, or ongoing SEO program.
3. Deliverable inventory
Lists strategy outputs, page or template types, content, designs, features, integrations, migration, analytics, testing, training, documentation, and launch work in countable or otherwise verifiable terms.
4. Exclusions and options
Names work not included and shows optional items separately. Common examples include photography, translation, legal writing, large data cleanup, paid media, ongoing content, premium licenses, and third-party configuration.
5. Assumptions and dependencies
States facts the plan relies on: timely client access, one approval owner, usable source files, a supported integration, a known content volume, or a third party's cooperation.
6. People and responsibilities
Identifies provider roles, client roles, decision-makers, subject experts, subcontracted work if relevant, and who owns each handoff.
7. Schedule and milestones
Shows sequence, target dates or durations, client review windows, dependencies, launch conditions, and what happens when an input is late. A launch date should not float free of content and approvals.
8. Review and acceptance
Defines what you inspect at each milestone, how feedback is consolidated, included revision rounds, correction of defects, acceptance criteria, and when silence does or does not count as approval.
9. Change control
Explains how either party documents a new request, estimates price and schedule impact, obtains authorization, and updates the plan. It should not turn every clarification into a change or make new work unlimited.
10. Price and payment
Separates fixed, estimated, hourly, usage-based, optional, reimbursable, and third-party costs. It names deposit, milestone, final payment, taxes if applicable, invoice timing, and any late-payment consequence.
11. Ownership, licenses, and accounts
Explains ownership of approved work, pre-existing tools, fonts, photos, code, plugins, and content; identifies client-controlled accounts; and states what is delivered after final payment.
12. Launch, warranty, and support
Covers prelaunch testing, backups, redirects, DNS responsibility, monitoring, defect correction, training, maintenance choices, support channels, response expectations, and the boundary between support and new work.
Make deliverables testable
Testable does not mean prescribing every keystroke or visual choice. It means both sides can tell whether the promised output exists and meets agreed conditions. The W3C explains that WCAG success criteria are testable and organized under perceivable, operable, understandable, and robust principles. If accessibility is in the proposal, ask which standard and conformance level guide the work, which pages or components are tested, what methods are used, and what content duties remain with your team. A broad compliance guarantee without scope or method deserves careful review.
Find assumptions that can change the price
Assumptions worth converting into explicit decisions
| Hidden assumption | Question to resolve it |
|---|---|
| The old content is ready to move | Who inventories, cleans, rewrites, enters, formats, checks, and approves each content type? |
| The integration will be simple | Which system, plan, API, fields, permissions, environments, error cases, and vendor contacts are included? |
| Feedback will be quick | Who gives one consolidated response, within how many business days, and what happens if reviewers disagree? |
| The current URLs can change freely | Who inventories organic landing pages, maps redirects, updates internal links, verifies them, and monitors errors? |
| The client owns everything | Which custom deliverables transfer, which third-party items remain licensed, and what accounts or files are handed over? |
| Hosting includes care | Who updates software, monitors availability and security, restores backups, fixes defects, and changes content? |
A redesign proposal deserves a specific migration section. Google's site-move documentation recommends mapping old URLs to new ones, using permanent server-side redirects, updating internal links, verifying the site, and monitoring the transition. A proposal should assign the inventory, redirect map, implementation, validation, and post-launch review. It should also say whether unchanged URLs will stay unchanged. Search visibility can still fluctuate, so a responsible provider explains risk and monitoring rather than guaranteeing an identical result.

Federal acquisition guidance for performance work statements emphasizes required results, measurable performance standards, and ways to assess performance. A private web project is not governed by those procurement rules, but the drafting principle is…
Compare proposals on one sheet
- Copy every deliverable into a row. Mark included, optional, excluded, unclear, or assigned to your team for each provider.
- Add the named person responsible and the evidence of completion. A promise without an owner or acceptance method remains hard to manage.
- Normalize quantities. Separate unique page designs from pages populated in an approved template, and separate writing from copying supplied text into the site.
- Add all recurring and third-party costs over the same time period. Include platform, hosting, domains, premium tools, maintenance, support, and usage charges.
- Estimate internal work. A lower-priced offer may require more writing, project management, image sourcing, data entry, testing, or vendor coordination from your team.
- List open risks and assumptions. Do not award an optimistic interpretation to a vague line; ask the provider to revise or clarify it in writing.
Check ownership before the signature page
The proposal should say whether your business will be the registrant of its domain and administrator of critical platform, hosting, analytics, tag-management, search, and form accounts. ICANN tells domain registrants to understand processes for managing, transferring, renewing, and restoring registrations. Ask which account will hold the domain, which contact receives notices, and how access is recovered. For creative work and code, separate custom deliverables from provider tools and third-party licenses. Your lawyer can help align the proposal, contract, intellectual-property terms, and your jurisdiction.
Use the proposal to prepare the next conversation
Mark every unclear noun—“pages,” “SEO,” “copy,” “migration,” “responsive,” “accessible,” “training,” “support,” and “optimization”—and ask for the action, quantity, responsibility, and acceptance condition behind it. Then review the matching questions to ask a web designer. If you want a reference point for how a provider describes its offer, compare the scope language with Web Respawn's website design service. The goal is not to force every proposal into the same format; it is to make every important difference visible before you choose.
Is a web design proposal the same as a contract?
Not necessarily. A proposal usually describes the recommended work and commercial offer. A contract states the binding terms, and it may incorporate the accepted proposal by reference. Make sure the documents agree about scope, price, ownership, timing, changes, termination, and support; seek legal advice for your situation.
Should a proposal include a homepage mockup?
It can, but a speculative mockup is not proof of a sound process or final result. Without discovery, content, and requirements, it may reward surface styling. Give more weight to relevant work, reasoning, scope clarity, and the planned design process.
How detailed should the page list be?
Detailed enough to distinguish unique templates, repeated pages, migrated pages, newly written pages, and later phases. For a large site, a content inventory or sitemap attachment can carry the detail while the proposal summarizes counts and responsibilities.
What if the project cannot be fully scoped yet?
Use a paid discovery phase with its own deliverables, timeline, price, and decision point. The proposal should explain what discovery will resolve, what estimate can be given now, and whether either party can stop before the build commitment.
Should recurring website costs appear in the proposal?
Yes. List known hosting, platform, domain, license, maintenance, support, usage, and renewal costs; show who bills each one and how prices may change. Separate required costs from optional services.
Can I ask a provider to revise a proposal?
Yes. Ask for corrections and material clarifications before acceptance. If you request new work, expect the price or schedule to change. Keep the final accepted version attached to or clearly referenced by the contract.
Evidence behind the guide
Sources and further reading
- FAR 37.601 — Performance-Based Acquisition: GeneralU.S. General Services Administration
- FAR 37.602 — Performance Work StatementU.S. General Services Administration
- Site Moves and MigrationsGoogle Search Central
- WCAG 2 OverviewW3C Web Accessibility Initiative
- Information for Domain Name RegistrantsICANN
Continue on Web Respawn
Pages that actually connect to this decision.
These links are selected for the subject of this guide. They are not a generic service dump.
Explore the strategy, content, design, build and launch foundation.
Open page ↗RELEVANT PAGEWebsite & Growth ServicesSee the complete Web Respawn service system in one place.
Open page ↗RELEVANT PAGEAbout Web RespawnSee the company, approach and standards behind the work.
Open page ↗RELEVANT PAGEWebsite Design FAQsGet concise answers about scope, timelines, ownership, SEO and care.
Open page ↗







