How to Evaluate a Web Designer's Proposal

A good website proposal should show that the supplier understands the business problem and has a controlled way to deliver the result. Attractive examples and a persuasive presentation are useful, but they do not replace a clear scope, ownership terms, content responsibilities and acceptance criteria.

Use the same written brief for every supplier. Otherwise, differences in price may simply reflect different assumptions.

Check whether the proposal answers the brief

Look for a clear response to:

• the website objective;
• the priority audience;
• required pages and functions;
• existing-site migration;
• content production;
• ownership and handover;
• ongoing maintenance;
• budget and timing constraints.

A proposal that spends pages describing the supplier but barely addresses your situation is not yet a project plan.

Separate deliverables from general promises

Promises that need a concrete definition

Proposal wording	What to ask
SEO-friendly website	Which technical, structural and content tasks are included, and which are not?
Mobile responsive	Which templates, widths, devices and journeys will be tested?
Secure	Who manages updates, backups, access, monitoring and recovery?
Optimised for speed	What will be measured, on which representative pages and at what stage?
Content support	Who writes, edits, enters, approves and fact-checks each page?
Training included	How long, for whom, on which tasks, and is documentation provided?

Understand the proposed platform

The proposal should explain why the recommended platform fits the requirements. Ask:

• which standard functions it provides;
• which paid extensions or apps are required;
• what renews each year;
• who maintains compatibility and updates;
• what can be exported;
• what happens if you change supplier;
• whether custom development is genuinely necessary;
• which requirements the platform cannot meet cleanly.

Be cautious when a supplier recommends the same technology for every project without discussing alternatives or limitations.

Check the page and content scope

“Up to 20 pages” does not explain what will be created. Confirm:

• the page list and templates;
• whether existing content is migrated or merely copied;
• whether copywriting is included;
• who supplies photographs and licences;
• how many rounds of content and design revision are included;
• whether product, location or case-study data counts as individual pages;
• whether redirects from old URLs are included;
• who checks the final entered content.

Review the process and decision points

A credible proposal normally describes stages such as planning, structure, content, design, development, testing, launch and handover. It should show what the business must approve before work proceeds.

Ask what happens if:

• content is late;
• the scope changes;
• a third-party integration does not work as expected;
• the supplier misses a milestone;
• the business pauses the project;
• a critical fault appears after launch.

Examine ownership and access

The contract should make clear:

• who registers and controls the domain;
• who owns the hosting or platform account;
• which administrator access the business receives;
• who owns approved copy, photography and design work;
• which assets are licensed rather than transferred;
• whether source files are included;
• how data and content can be exported;
• what is handed over at the end of the relationship.

Do not assume that paying for a website automatically transfers every file, licence or account.

Compare the total cost

Costs to identify before accepting a proposal

Cost group	Examples
One-off project	Planning, design, build, migration, content, photography, configuration and launch
Recurring platform	Hosting, subscriptions, domains, email, themes, plugins, apps and licences
Transaction	Payment, booking, marketplace or messaging fees
Support	Updates, backups, monitoring, fixes and response arrangements
Future change	New pages, design changes, integrations and content entry

Compare the likely cost over three years. A low build price may depend on high recurring fees or a closed arrangement that is expensive to leave.

Assess evidence of competence

Review work that is relevant in complexity, not only visually similar. Ask what the supplier actually delivered and whether the example is still live.

Useful evidence includes:

• a clear explanation of the problem and approach;
• working mobile journeys;
• examples of content-heavy or technically similar projects;
• references you are permitted to contact;
• honest discussion of limitations and lessons;
• documentation or testing examples with confidential details removed.

Do not rely on screenshots alone. They do not prove ownership, performance, accessibility, support quality or business results.

Look for unrealistic claims

Warning signs include:

• guaranteed Google rankings or traffic;
• an unusually low fixed price for an undefined scope;
• pressure to approve immediately;
• no discussion of content or migration;
• accounts controlled only by the supplier;
• custom development proposed for ordinary functions without justification;
• no exclusions, assumptions or ongoing costs;
• no testing or acceptance process;
• vague ownership language.

Use a weighted comparison

Score proposals against criteria that matter to the project. A possible weighting is:

• understanding and approach — 25%;
• scope and deliverables — 20%;
• technical suitability and ownership — 20%;
• content, migration and testing — 15%;
• ongoing cost and support — 10%;
• relevant evidence and communication — 10%.

Change the weighting for your situation. Price should be considered, but the cheapest proposal should not win by default if important work is absent.

Clarify before negotiating

Send each supplier a written list of unresolved points and ask for the proposal to be updated. Do not rely on important promises made only during a call.

The next practical step is to create a side-by-side table showing scope, exclusions, ownership, recurring costs, support and acceptance criteria. The strongest proposal is normally the one that removes uncertainty rather than the one that makes the largest promise.