Red Flags to Watch for in Web Design RFP Responses

Most proposals look competent. They are well formatted, confident, and full of reassuring language. The differences that matter are usually small and specific — a missing line item, a claim stated without a method, a timeline with no dependencies. These are the ones worth stopping on.

This is a companion to our guide on evaluating proposals, which covers the scoring process. This one is just the warning signs.

The scope is described in adjectives

"A modern, user-friendly, fully responsive website optimised for conversions." Every proposal says this. None of it is a deliverable you can hold anyone to.

What you want instead is counts and nouns: how many templates, how many pages migrated, which integrations, how many rounds of review. If the proposal cannot be turned into a checklist, it cannot be managed and it cannot be compared to the one next to it.

Accessibility is claimed without a method

"Fully ADA compliant" and "built to accessibility best practices" are the two most common phrases and neither means anything testable. ADA compliance is not a technical standard, and "best practices" is not a verification method.

A serious answer names the standard, describes automated plus manual testing, says who does the manual testing, and states what documentation you receive. Anything less has not been scoped, which means it has not been priced — see Section 508 compliance for what the real requirement looks like.

An overlay widget is the accessibility solution

If a proposal answers accessibility with a third-party overlay or "accessibility widget," treat that as disqualifying on the accessibility criterion. Overlays cannot repair heading structure, unlabelled fields, keyboard traps or contrast in the underlying markup, and they have featured in accessibility litigation rather than preventing it.

A vendor proposing one either does not understand the requirement or is hoping you do not.

Migration is mentioned but not quantified

Look for a number. "Content migration included" with no page count is an invitation to a change order — the vendor will migrate what they assumed, and the difference becomes your problem.

The related flag is silence on URLs. If the proposal does not commit to preserving existing addresses or delivering a redirect map, assume your archive breaks on launch day. Our migration checklist covers what a real plan looks like.

The timeline has no dependencies on you

A timeline showing only vendor tasks is a fiction. Real projects wait on content approvals, stakeholder reviews, legal sign-off and boards that meet monthly.

A proposal that names your dependencies is telling you where it will slip and inviting you to plan for it. One that does not is preserving the option to blame you later.

The timeline is implausibly short

Be as sceptical of a ten-week timeline for a 400-page migration as you would be of an eighteen-month one for a brochure site. On public-sector and nonprofit projects the constraint is usually your review cycle, not the vendor's capacity, and a vendor promising speed has usually not read your governance section.

You cannot tell who will do the work

"Our team of certified experts" is not an answer. Ask for named people with relevant experience, and notice whether the people in the pitch are the people on the project — the gap between agency sales teams and agency delivery teams is one of the most common post-award complaints.

The references are unreachable or irrelevant

References from a different sector, or from five years ago, or a list of logos with no contacts, are all soft refusals. Ask for two references from comparable projects in the last two years, and actually call them with a specific question — "what went wrong, and how did they handle it?"

Nothing is out of scope and nothing is a risk

A proposal with no exclusions, no assumptions and no risks has not been thought about. Every real project has content that will not be ready, an integration that may not cooperate, and an approval that may take longer than planned.

A vendor who states assumptions plainly — "priced for up to 400 pages; content supplied by client by week 4" — is protecting both of you. One who states none is preserving ambiguity to be resolved later, in their favour.

Ownership is vague or conditional

Read carefully for who owns the code, the content, the design files and the accounts at the end, and whether ownership depends on retaining the vendor for hosting or support. Ambiguity here is how organizations end up unable to leave a proprietary CMS without rebuilding.

The related flag is a domain or hosting account registered to the vendor rather than to you — covered in handover documentation.

Post-launch support is undefined

"Ongoing support available" is not a commitment. What is covered, for how long, at what response time, at what cost after the initial period? An undefined support arrangement becomes an invoice you did not budget for, or a site that stops being patched.

The price is dramatically lower than everyone else's

An outlier low bid is not usually a bargain. It normally means something was excluded, the page count was underestimated, or the accessibility work was not scoped. Build the line-item grid across all proposals and the omission usually appears immediately.

The reverse is also worth checking: an outlier high bid sometimes reflects a genuinely larger scope the others missed, and occasionally that vendor is the only one who read your requirements properly.

Everything you asked for is agreed to enthusiastically

The most underrated warning sign. A proposal that accepts every requirement, every timeline and every constraint without a single caveat has either not read the document carefully or intends to renegotiate after award.

Candour at proposal stage is the best available predictor of candour during delivery. A vendor who tells you the timeline is unrealistic, or that a requirement will cost more than you have budgeted, is showing you how they will behave when something goes wrong — which is the thing you are really trying to find out.

If you want a second read on the technical sections of proposals you have received, we will answer questions even when we are not bidding. The RFP and procurement FAQ covers the common ones.