A website RFP is meant to save you time. Most of them do the opposite. They run twenty pages, ask for things the writer does not actually need, and still leave every responding agency guessing at the one thing that matters: what a good outcome would change about the business.
A sharper RFP gets you sharper proposals. That is the whole game. This is how to write one.
What an RFP is actually for
An RFP (request for proposal) is a document you send to a short list of agencies so they can propose how they would build your site and what it would cost. That is the mechanical definition. The real purpose is narrower. You want to give a small set of qualified teams enough context to respond with something specific, so you can compare proposals on substance instead of polish.
That framing changes what goes in. An RFP is not a contract. It is not a full technical specification. It is not a way to extract free strategy from people you have not hired. It is an invitation to a serious conversation, written well enough that the replies are worth reading.
The best RFPs are shorter than people expect and blunter than people are comfortable with. They state what the business is trying to achieve, where the current site falls short, and what success would look like in numbers. Then they get out of the way.
An RFP is not a spec. It is an invitation, written well enough that the replies are worth reading.
What to put in a website RFP
Six things earn their place. Most of the rest is padding that makes the document look thorough while telling an agency nothing.
Context about your organisation. Who you are, what you sell, who buys it. Two paragraphs is plenty. A team that understands your market will propose differently than one filling in a template, and you want to be able to tell them apart.
The problem, stated honestly. Not “we need a redesign.” The actual problem. The site does not convert. Editors cannot publish without a developer. Mobile visitors bounce before the page settles. Lead with the thing that is broken, because that is what you are paying to fix.
Goals, and how you will measure them. Three at most, each with a number or a clear signal attached. “Increase qualified demo requests” is a goal. “Make it feel modern” is a mood. If you cannot measure it, you cannot tell afterward whether the project worked, and neither can the agency.
Scope and the constraints you already know. A rough page count, the systems it has to integrate with, any CMS preference, accessibility or compliance requirements, the languages you publish in. If you have a hard launch tied to an event, say so. Real constraints help good agencies scope accurately. Only weak ones resent them.
Budget, or at least a band. This is the section people cut, and cutting it is the costliest decision in the whole process. More on that below.
Logistics. The selection timeline, how to submit, who the decision-makers are, and when you expect to award. Make it easy to respond and you raise the quality of who bothers.
Say something about budget
Withholding the budget feels like negotiating leverage. It is the opposite. It guarantees you a stack of proposals scoped to different realities, none of which you can compare side by side. A team that assumes you have fifteen thousand will design a different project than one that assumes you have a hundred and fifty thousand, and you will have learned nothing useful about either.
You do not have to name a single figure. A band works fine: state that you expect the project to land between two numbers. That one sentence does more to produce comparable, honest proposals than anything else in the document. If you are unsure where to set the band, scoping a web project walks through how scope and cost move together so the range you give is grounded.
What to leave open on purpose
Detail and prescription are different things, and an RFP needs the first without the second.
Specify the outcome. Leave the method open. If you dictate the tech stack, the page structure, and the design direction, you have hired the agency to type, and you have thrown away the reason to hire one in the first place. The teams worth working with have opinions about how to solve your problem. An over-specified brief hides exactly the thinking you are trying to evaluate.
Here is a quick test. For each requirement, ask whether it is a genuine constraint or a guess at a solution. “Must work with our existing Salesforce instance” is a constraint. “Must be built in WordPress” usually is not, unless you have a real operational reason. Keep the constraints. Turn the guesses into questions and ask for a recommendation instead. You will learn more from how a team reasons toward an answer than from whether it agreed with your hunch.
The questions that separate good agencies from bad ones
Add a short list of questions every responder has to answer in writing. The answers tell you more than any cover page. Ask:
- Who specifically will do the work, and are they the people we are speaking with now?
- Walk us through a project where the scope changed mid-build. What did you do about it?
- How do you handle content, and what do you need from us, by when?
- What would you push back on in this brief?
That last one is the most revealing question you can ask. An agency that answers “nothing, this looks great” is selling. One that replies “your timeline and your page count do not agree, and here is why” is thinking. You want the second kind in the room. For a fuller filter on reading the replies, how to choose a web development agency breaks down what the answers actually signal.
Common mistakes that sink an RFP
The same few errors show up again and again, and each one quietly lowers the quality of what comes back.
Sending it to fifteen agencies. A wide net does not get you better odds. It gets you thin, hurried proposals from teams that know they are one of many. Pick three or four you genuinely respect and give each enough to work with.
Copying a template you do not understand. Boilerplate RFPs ask for response times, SLAs, and uptime guarantees on a marketing site that needs none of it. Every clause you cannot explain is a clause that invites a padded answer.
Asking for free design or strategy. Requesting mockups or a detailed plan before anyone is paid filters for the wrong agencies. The good ones decline. The desperate ones comply, and you have selected for desperation.
No named decision-maker. If the responders cannot tell who signs off, they cannot tell who to convince, and proposals drift toward the safe and generic. Name the person.
Treating it as a one-way document. The best agencies will want a conversation before they commit a price. Leave room for one. A short call before proposals are due nearly always produces better proposals.
How Strynal approaches website RFPs
We read the problem statement first and the requirements list second, because the requirements are often a client’s best guess at a solution, and the problem is the thing we were actually hired to solve. A good RFP gives us both. A great one tells us what success would change about the business, then trusts us to recommend the route.
Strynal starts every engagement on a blank page. That is easier when an RFP describes outcomes rather than dictating methods, because it leaves space for the thinking that is the point of bringing in a studio at all. When we respond, we say what we would push back on, who would do the work, and how we would scope it in phases so the budget stays honest. If that sounds like the kind of partner you are looking for, working with a boutique agency explains how we run an engagement from both sides of the table.
If you are drafting an RFP for a website or app build and want a second read before it goes out, send it over. A sharper brief gets you better proposals, and we are happy to help you write one even before you have decided who builds it.