What a Good Website Proposal Should Include

A proposal is a model of the project

The best website proposals reduce uncertainty. They show what the agency believes the problem is, what it intends to make, what it needs from the client, how decisions will be made, and what would change the price or date.

A beautiful deck can still be a poor proposal. If it cannot answer who writes the copy, how many templates are included, what happens to old URLs, or who owns the code, it has postponed the difficult conversation rather than resolved it.

Use the proposal as an early sample of the agency's thinking. Precise work usually begins with precise definitions.

1. The problem and intended outcome

The proposal should restate why the project exists in language specific enough for the client to correct.

Weak:

> Redesign the website to create a modern digital presence.

Useful:

> Reorganise the service offer so qualified buyers can identify the right capability, verify relevant work, and reach the team without navigating the current internal company structure.

The second statement gives design, content, and measurement something to answer. The first gives everyone permission to debate taste.

Look for:

• primary audiences and their important tasks;
• current problems supported by evidence;
• business constraints and non-negotiables;
• what should be measurably better after launch;
• outcomes the agency does not claim to control.

Be wary of guaranteed rankings, conversion lifts, or revenue. A website can influence those outcomes, but no agency controls demand, pricing, competition, sales follow-up, or search algorithms.

2. A scope expressed in systems, not just pages

Page count is a weak description of a website. Fifty articles may use one template; six marketing pages may each require a different structure.

The proposal should specify:

• sitemap or estimated URL count;
• unique page templates;
• reusable components and important states;
• CMS content types and relationships;
• forms, search, filtering, accounts, or other functionality;
• third-party integrations and the direction data moves;
• languages, regions, roles, and permissions;
• content migration volume;
• analytics, consent, SEO, accessibility, and performance work.

If discovery must resolve some of these, the proposal should say so and explain how the later scope will be approved. “To be confirmed” is acceptable when paired with a decision process; it is dangerous when paired with a fixed promise.

3. Deliverables for every phase

Activities describe effort. Deliverables describe what the client receives.

Instead of “two weeks of discovery”, look for outputs such as an agreed sitemap, prioritised requirements, content inventory, technical-risk register, and delivery plan.

A typical custom website proposal may include:

The exact phases can change. Each should still end with an observable result and an approval owner.

4. The actual delivery team

The proposal should identify the roles involved and distinguish named, committed people from general agency capability.

Ask:

• Who leads the project after the sale?
• Who designs and who builds?
• Who owns content, SEO, QA, and migration?
• Which work is subcontracted?
• How many projects will the key people run concurrently?
• Who has authority when disciplines disagree?

For a small studio, one person may cover several roles. That can be efficient when the boundaries are honest. A list of eight roles is not reassuring if the client never meets seven of them.

5. Responsibilities on both sides

Many delays are client-side dependencies disguised as agency dates. A responsible proposal names them.

It should state who will:

• supply and approve copy;
• provide brand assets, photography, legal text, and translations;
• grant access to the domain, hosting, CMS, analytics, CRM, and other systems;
• consolidate stakeholder feedback;
• make final decisions;
• enter or migrate content;
• approve third-party fees;
• coordinate legal, security, or procurement review.

Look for response-time assumptions. If the timeline expects feedback within two working days, that obligation should appear beside the production schedule.

6. Timeline, dependencies, and decision gates

A proposal should show sequence, not just a launch date. It should identify which work can overlap and which approval unlocks the next phase.

Useful schedules include:

• start conditions;
• phase windows and review dates;
• client dependencies;
• external dependencies;
• content deadlines;
• contingency for integrations or migration;
• launch and stabilisation periods.

If the date is fixed, the proposal should identify what scope can move. Fixed scope, fixed cost, fixed date, and unresolved requirements cannot all remain fixed when reality changes.

7. Fees that connect to scope

The price should be understandable without requiring the agency to reveal its internal payroll.

At minimum, the proposal should separate:

• professional fees;
• optional work;
• third-party licences and subscriptions;
• hosting or infrastructure;
• taxes where applicable;
• ongoing maintenance or support;
• expenses or usage-based charges.

Payment milestones should correspond to real stages or periods. Avoid comparing totals before normalising scope: one proposal may include content planning, migration, accessibility, redirects, and post-launch support while another begins with approved designs and ends at deployment.

8. Assumptions, exclusions, and change control

This is where mature proposals become more valuable than optimistic ones.

Common assumptions include the number of templates, content readiness, data quality, API availability, stakeholder count, supported browsers, languages, feedback rounds, and migration volume.

Common exclusions include copywriting, photography, translation, legal review, paid software, complex data cleaning, ongoing SEO, and changes to third-party systems.

The change process should answer:

1. How is a new request identified?
2. Who estimates its effect?
3. Does it change cost, date, or existing scope?
4. Who approves the trade-off?
5. Where is the decision recorded?

Change is normal. Invisible change is what damages projects.

9. Quality and acceptance criteria

“Responsive, fast, accessible, and SEO-friendly” sounds complete while defining almost nothing.

The proposal should state how the team will test:

• supported browsers and representative devices;
• keyboard navigation, focus, labels, contrast, and semantic structure;
• forms and failure states;
• page templates against agreed performance budgets;
• metadata, canonicals, redirects, sitemap, and structured data;
• CMS editing and permissions;
• analytics and consent behaviour;
• integrations, security controls, backups, and rollback.

Acceptance criteria should describe when agreed work is complete and distinguish a defect from a new preference.

10. Ownership, access, and the exit

The proposal or attached contract should state what happens after payment.

Clarify ownership and access for:

• domain and DNS;
• hosting and deployment;
• design source files;
• custom code and repository;
• content and original assets;
• CMS accounts;
• analytics, tag manager, and Search Console;
• paid fonts, plugins, stock media, and other licences.

Third-party software retains its own licence. Custom work should not be used as an excuse to keep the client dependent on accounts they do not control.

11. Launch, warranty, and ongoing support

“Launch included” should expand into a real release plan: backups, redirects, production checks, analytics verification, monitoring, and rollback ownership.

After launch, distinguish:

• warranty: correcting defects in agreed work;
• maintenance: updates, monitoring, backups, and security work;
• improvement: new features, experiments, content, SEO, or conversion work.

Ask for the warranty period, response process, service windows, and what becomes chargeable. A maintenance retainer can be valuable; it should not be required merely to correct incomplete delivery.

A 12-point comparison checklist

Before accepting a proposal, confirm that you can answer yes to each statement:

1. The problem is described accurately.
2. Outcomes are credible and measurable.
3. Templates, functionality, content, and integrations are bounded.
4. Each phase produces named deliverables.
5. The delivery team is known.
6. Client responsibilities are explicit.
7. The timeline includes review and dependency assumptions.
8. Fees and recurring costs are separated.
9. Exclusions and changes have a process.
10. Quality claims have test methods.
11. Ownership and access are clear.
12. Launch and post-launch responsibilities are defined.

A proposal does not need to be long. It needs to make the consequential parts of the project visible.

Common questions