It is procurement season, and the website RFPs landing in agency inboxes this summer look much like they did five years ago: a forty-row feature matrix, a request for three case studies, and a scoring rubric that gives ‘understanding of requirements’ more weight than any evidence of it. Here is the uncomfortable truth from the other side of the table: every agency ticks every box. A feature checklist does not select for competence — it selects for confidence.
Universities, societies and charities do not have procurement teams full of web specialists, and they should not need them. But a few changes to what you ask — and how you weight the answers — will tell you more than any matrix.
Ask to see the editor, not the homepage
Any agency can show you a beautiful homepage. Ask instead for a screen recording of a content editor updating a real page on a site they built. You will learn immediately whether the site is genuinely editable by your team or held together by a developer on retainer. If the recording shows a page-builder interface groaning under custom widgets, you have just seen your next five years of frustration.
Ask how accessibility was tested, not whether it is supported
‘Do you build accessible websites?’ gets a yes from everyone. Try: ‘Describe how you tested your last launched site against WCAG 2.2 AA, what you found, and what you fixed.’ A specialist will answer with tools, findings and specifics. A generalist will answer with a paragraph about how much they care. The difference is unmistakable once you have seen both — and with the European Accessibility Act now in force and enforcement maturing, it is not an academic distinction.
Score the four-year cost, not the year-one price
The build quote is the smallest number in the relationship. Ask every bidder for a four-year total: build, hosting, care, licence renewals for every commercial plugin in their stack, and — the one nobody volunteers — the cost of the eventual rebuild if their platform choices lock you in. A slightly dearer native build that your own team can run routinely beats a cheap build with a heavy retainer stapled to it.
Ask who does the work
The people in the pitch meeting are rarely the people in the repository. Ask directly: who will design, who will build, who answers when something breaks, and how senior are they? Small specialist teams tend to do well on this question, which is precisely why larger bidders hope you will not ask it.
Ask what happens when you leave
- Who owns the theme, the content models, and the hosting account?
- Can another supplier take the site over without paying to rebuild it?
- Is there documentation a newcomer could actually follow?
An agency confident in its work will answer these cheerfully, because exit-friendly builds are how it wins work in the first place. Hesitation here is the clearest red flag an RFP can surface.
And ask for less
The best briefs we have answered were four pages long: what the organisation is, what is not working, what success looks like, and the questions above. Shorter RFPs get better answers because bidders spend their hours thinking about your problem rather than formatting responses to boilerplate. Weight the questions that discriminate, drop the ones every bidder passes, and leave room for a bidder to tell you something you did not ask.
A good RFP reads like the start of a working relationship. A bad one reads like a shield against blame. Suppliers can tell the difference on page one — and so, eventually, will you.
