How to Evaluate Website Design and Development Proposals

You have six proposals on the table. They range from $38,000 to $210,000, three of them look nearly identical because they came from the same template, and the committee meets on Thursday. The hard part of a procurement is not writing the RFP — it is telling the difference between a proposal that is cheap and one that has quietly omitted half the work.

This is a scoring approach written from the vendor side, which means it describes what the differences in those documents actually signify. If you are still drafting the solicitation, the companion piece on writing a government website RFP covers how to structure it so the responses are comparable in the first place.

Normalise the scope before you look at price

Price differences on website projects are usually scope differences wearing a disguise. Before comparing totals, build a grid: rows for each line item — discovery, design, development, content migration, content writing, accessibility testing, training, post-launch support, hosting — and a column per vendor. Fill in what each one actually included.

The grid usually explains the range on its own. The $38,000 proposal migrates 50 pages and assumes you write the content. The $210,000 one includes 400 pages of migration, a full content rewrite and a year of support. Neither is wrong; they are pricing different projects, and only one of them matches what you asked for.

If a proposal is silent on a line item, treat it as excluded and ask. Silence is not inclusion, and the conversation about it after award is far more expensive than the conversation now.

Score the accessibility answer on verification, not intent

Every proposal will say it meets accessibility requirements. The differentiator is how conformance gets verified. Look for three things: a named standard, an explicit mix of automated and manual testing, and a stated deliverable.

A strong answer reads like: builds to WCAG 2.2 AA, automated testing across the full site, manual keyboard and screen-reader passes on the key journeys, findings documented and remediated before launch. A weak answer says "fully ADA compliant" and names a plugin or overlay widget. Overlays cannot fix heading order, unlabelled form fields, focus traps or contrast failures in the underlying markup, and they have been named in accessibility litigation — a proposal that leans on one is telling you it has not scoped the real work. Our page on Section 508 compliance covers what the standard actually requires.

Check whether the migration plan is a plan

Content migration is where budgets fail. Look for a stated page count, a stated method — manual, scripted, or a mix — and an explicit commitment on URLs. If the proposal does not say what happens to your existing addresses, assume nothing does, and expect your agenda archive to start returning 404s the week after launch.

A good sign is a vendor who asks how you counted your pages, or who states an assumption clearly: "priced for up to 400 pages migrated; above that, $X per additional 100." That is someone who has done this before and is protecting you from a change order as much as themselves.

Look for named people, not a capability statement

Ask who will actually do the work and score the answer. Proposals that name the designer, the developer and the project lead — with their relevant experience — are making a commitment you can hold them to. Proposals that describe "our team of certified experts" are not.

This matters more than it sounds. Agency sales teams and agency delivery teams are frequently different populations, and the gap between the people in the pitch and the people on the project is one of the most common post-award complaints.

Call the references, and ask a specific question

Reference checks are usually a formality because the questions are generic. Ask one specific thing instead: "What went wrong on the project, and how did they handle it?" Every project has something. A reference who cannot name anything either had a trivial project or is not being candid; a reference who describes a real problem and a reasonable response has told you what you needed to know.

Ask one more: "Who maintains the site now, and can your own staff edit it?" That answers the handover question better than any section of the proposal.

Read the timeline for dependencies

A timeline that shows only vendor tasks is a fiction. Real projects wait on you: content approvals, stakeholder reviews, legal sign-off, decisions from a board that meets monthly. A proposal that names your dependencies — "content approval within 5 business days per round" — has thought about how the project actually runs and is telling you where it will slip if you are slow.

Be suspicious of unusually short timelines. On a public-sector project, the constraint is rarely the vendor's capacity; it is your review cycle. A vendor promising a 10-week launch for a 400-page migration with a committee approval process either has not read the governance section or is planning to blame you for the overrun.

Weight the criteria before you open the envelopes

Agree the weights before reading proposals, and score each criterion independently rather than forming an overall impression and back-filling numbers. A workable default for a website project: technical approach 30%, relevant experience 20%, accessibility approach 15%, team and references 15%, price 20%.

Whatever you choose, avoid pure lowest-price scoring. On website work it reliably selects the vendor who understood the scope least, and the saving is recovered through change orders within the first quarter.

Notice who told you something you did not want to hear

The most useful signal in a stack of proposals is candour. A vendor who says your timeline is unrealistic, or that a requirement will cost more than you have budgeted, or that part of your scope is unnecessary, is showing you how they will behave when something goes wrong mid-project — which it will.

Every proposal that agrees to everything is either not reading carefully or planning to renegotiate later. Ours occasionally tells buyers we are not the right fit, and points them somewhere better suited; we would rather do that at proposal stage than at week six.

A scoring checklist

For each proposal, confirm: every line item priced separately and none silently omitted; a named accessibility standard with a stated verification method; a migration plan with a page count and a URL commitment; named delivery staff; references you can call; a timeline that names your dependencies; a clear statement of what you own at the end; and an explicit scope for post-launch support.

Score those, then look at price. In that order, the cheap proposal that omitted migration stops looking cheap.

If you are running an evaluation now and want a second read on the technical sections, we are happy to answer questions even when we are not bidding — the RFP and procurement FAQ covers the common ones, and you can send us a solicitation for a fit review. Our approach to government web design and nonprofit website design sets out what we would be proposing against.