Method & RFP
If you are searching for a website RFP or a requirements spec you can send, you are usually here: you need a new site, someone has asked for three bids, and the document you send is either a wish list or a solution you have already chosen. Someone writes 'WordPress, 12 templates, a slider on the home page'. Someone writes 200 features. Someone sends a moodboard and calls it an RFP.
The agency post is about the ten questions you ask before the contract. The discovery post is about the week that replaces the spec nobody can estimate from. This one is about the document you send out so three parties can answer the same thing at all. An honest RFP is not a solution. It is the truths launch has to hold — and permission for discovery to move the stack.
TL;DR
The main points
- You can compare bids when everyone is bidding on the same launch truths — not on a solution of their own.
- A spec with 200 features is a wish list. It hides what you actually want to be true on day one.
- Write what you already have: domain, content, integrations, who owns DNS and analytics.
- Write what is out. Without an out-list people bid on a different product.
- The solution — WordPress, Next.js, Shopify — belongs as a proposal you want justified, not as a requirement you cannot explain.
- Discovery may move the stack. An RFP that locks the framework before anyone has seen the content is a theatre RFP.
Why this matters at all
An RFP you cannot compare costs weeks after you have chosen. One bid is a theme. The second is a custom Next.js site. The third is 'we will figure it out in a workshop'. You pick on a feel for price and chemistry, and discover in week four that you bought three different products. You think you have a vendor problem. You have a document problem.
Teams write the wrong spec. They specify a slider, a template count and a CMS name because that is concrete. They forget who the site is for, what must be true at launch, and what already exists. Then you get three solutions that all 'meet the spec', and you cannot put any of them next to each other. The concrete part was the wrong concrete.
It is also an SEO and ownership question. If the RFP does not say that URLs must live, that you own DNS, and that you must be able to change vendor, people bid on a site you cannot move. If it does not say where the content comes from, people bid on empty templates. The spec is the first place you either take ownership — or give it away.
We write this because 'website requirements spec' has become a PDF you can send before you have a sentence about launch. An honest RFP is boring: audience, launch truths, what you have, what is out, how you decide, and that discovery may say no to your favourite stack. Without that sentence you have a wish list. You do not have an RFP you can defend to a board.
What a web RFP actually is — and what it is not
A web RFP is a document that asks several parties the same question: can you make these truths hold at launch, with this you already have, and with this out? The answer may be a solution. The question must not be one. When the question already says WordPress and 12 templates, you have not asked for advice. You have asked for a price on a decision you have not tested.
A requirements spec is the list of what must be true — not the list of widgets. 'An editor can publish an article without a developer' is a requirement. 'We want Gutenberg and a slider plugin' is a solution. 'The product can be shown in Danish and English with the same URL logic' is a requirement. 'We have chosen a headless CMS' can be right — if you can say why, and if you allow the answer to be no.
It is also not a contract. The RFP should make bids comparable. The contract comes after, when you have chosen, and when discovery has cut. Asking for a fixed solution on a wish list you yourself doubt is how you get a cheap-looking bid that splits when the content arrives. The agency questions test the partner. The RFP tests whether you asked the same question.
And it is not discovery. A week that produces decisions comes when you have chosen someone you dare sit in a room with. The RFP comes before. If you try to make discovery happen in the PDF, you get a spec nobody can estimate — exactly what the discovery week exists to replace. Write enough that you can compare. Do not write so much that you have locked what you have not seen.
What typically sits in the document — and what should
The first mistake is to list features you collected from three other sites. 'Newsletter, chat, blog, cases, login, shop, portal, booking.' That is five products. An honest RFP says which one must be true at launch, and which are phase two. Without that cut people bid on what they are good at, not on what you need.
The second mistake is to hide what you already have. Domain, Search Console, cookie setup, a PIM, a mail list, a shop that must live, an 80-page PDF of copy. If it is not in the RFP, the bids guess. Guesses become extras. Write the inventory. Also write what you do not have — 'no images, no product copy, DNS sits with a former vendor'.
The third mistake is to forget the out-list. 'Not a webshop this time.' 'Not an intranet.' 'Not that you host our mail.' Without outs every bid is a different scope. With outs you can see who respects the edge, and who sells you an extra product in the same PDF.
The fourth mistake is to ask for a price on what you have not cut, and then compare the numbers as if they were the same work. We do not show prices here — and you should not decide on a figure the document has not made comparable. Compare what they understood, what they said no to, and whether they dare move the stack. The number comes in the conversation when scope is the same.
Wish list vs. honest RFP — two documents, two kinds of bid
The wish list
Solutions and widgets. Hard to compare. Easy to nod at.
- WordPress, 12 templates, a slider, 'modern design'
- 200 features with no launch vs. later
- No inventory, no out-list
- Three bids that all 'meet the spec' and are three products
The honest RFP
Truths at launch. The same question to everyone.
- Who the site is for, and what must be true on day one
- What you have, and what is out
- Stack as a proposal you want justified — or left open
- How you decide, and that discovery may say no
What the document actually has to hold — in this order
Without this order you get three answers to three different jobs.
- 01
Who it is for, and what must be true at launch
Not 'a lovely site'. 'A buyer can understand the offer in two viewport heights and send a request without calling.' 'An editor can publish without us.' Two to four truths. If you have ten, you have not cut. Also write the languages and the market you actually want to rank in — Danish first, if that is the truth.
- 02
Inventory: what you have, and what you do not
Domain, GSC, analytics, cookie setup, CMS, PIM, shop, integrations, who owns DNS, where copy and images sit. 'We have a WordPress we want off' is inventory. 'We have no product copy' is inventory too. Bids that have not read it are bids on a different site.
- 03
The out-list, written as sentences
Not a bullet that says 'phase 2'. 'Not a webshop now.' 'Not a customer portal this time — we have forms.' 'Not that you move our mail.' If you are unsure about a line, it belongs in out or in discovery — not on a feature list you pretend is cut.
- 04
Stack as a view, not as a trap
If you want Next.js, write why — preview, performance, that you have an app next to it. If you do not know, write that you want a justified proposal, and that WordPress, Shopify or custom may win. Do not punish the answer that says no to your favourite framework. That answer is often the most expensive thing you can get for free.
- 05
How you decide, and what happens after the choice
Three bids, a conversation, a yes. Write what you look for: understanding, out-list, whether they dare move the stack, whether they can say no. Write that discovery comes after the choice, and that it may change the solution. An RFP that demands a fixed solution on uncertain content gets guesswork you later call extras.
“You can compare agencies when the document asks the same question. A wish list asks three.”
Public tender, SME email and SEO — the same duty, different traps
A formal tender — municipality, region, a procurement frame — has templates you cannot throw away. You still have to write launch truths and the out-list into the room the template gives you. If the template forces a CMS name, write why, and ask for a deviation answer. A tender that can only win by nodding gets nodding sites.
An SME sending a mail to three agencies does not need 20 pages. You need the five steps above on two pages. A moodboard may come along as taste, not as a requirement. 'We like this site' is fine. 'Build this site' is how you pay for a copy you cannot own. Let the mood be input. Let the truths be the requirement.
SEO belongs as truths, not as a plugin name. 'We must be able to keep URLs in a relaunch.' 'We need an honest title and description per page.' 'We want to see Search Console ourselves.' Those are requirements. 'We want an SEO plugin and 500 blog posts' is a solution, and often the wrong one. Relaunching without losing rankings is another post. Here the RFP just must not make the loss the default.
If you have already chosen an agency on chemistry, you do not need a theatre RFP. You need the same truths in a brief so you do not discover scope in week four. The document is not a ritual. It is the only way you and they can point at the same 'done'. Without it the conversation is pleasant, and the contract is a hope.
What you should typically do in the situation you are in
The left is what you typically say. The right is the next step we typically recommend.
Situation
We have 200 features and want three bids by Friday
Next step
Cut to launch truths and an out-list. Otherwise you are comparing three products
Situation
We wrote WordPress in the RFP because that is what we have heard
Next step
Write why — or open for a justified no. A receipt on an untested stack is not a bid
Situation
We do not know whether we need a portal, a shop or a marketing site
Next step
That is not an RFP yet. It is a conversation or a discovery week. The document cannot cut it for you
Situation
We want to compare on price before scope is the same
Next step
Compare understanding and nos first. The number in a conversation when the job is the same — not as a scoreboard on three PDFs
Situation
We have already chosen someone, and the 'RFP' is a ritual
Next step
Write a brief with the same five steps. The ritual PDF is how scope is discovered too late
Checklist before you send the document
If you are missing several of these, the sentence is an RFP — the contents are a wish list.
- Two to four launch truths, written as something you can point at on day one
- Inventory: domain, content, integrations, DNS, what you do not have
- An out-list in sentences, not a bullet that says phase 2
- Stack as a view with a reason — or open for a no
- How you decide, and that discovery may move the solution
- You can put three imagined answers side by side and see that they answer the same thing
Questions we hear again and again
What should a website requirements spec contain?
What must be true at launch, what you already have, what is out, and how you decide. Not 200 features and not a CMS name you cannot justify. An editor who can publish, URLs you can keep, a language you actually want to rank in — that is spec. A slider, a theme and 'modern design' are taste and solution. If you cannot cut to two to four truths, you are not ready for an RFP. You are ready for a conversation or a discovery week.
May we require WordPress, Next.js or Shopify in the RFP?
You may have a view. You have to write why, and you have to let a justified no count. 'We have editors who know WordPress' is a reason. 'We have heard Next.js is fast' is a hypothesis. An RFP that can only win by nodding at the stack gets nodding bids. That is how you buy the wrong solution for the right wish list. Stack choice is another post. Here the document must not make the choice a trap.
How long should the document be?
Short enough that three parties can answer the same thing without guessing. For an SME, two pages plus inventory is enough. A formal tender has templates — so put launch and outs into the room you have, instead of adding a feature list in an annex nobody reads the same way. Length is not clarity. A 40-page PDF that hides the out-list on page 37 is how you get three scopes.
When should we run discovery instead of sending an RFP?
When you do not know whether you need a portal, a shop or a marketing site — or when the content and integrations are so unclear that an honest bid would be guesswork. Discovery is five days with someone you have chosen. The RFP is the document before the choice. Mix them and you get a spec nobody can estimate, exactly what the discovery week is there to replace. Choose first if you already know the job. Discover first if you do not.
How do we compare bids without turning it into a price sheet?
Put the understanding side by side: did they repeat your truths, or did they sell you a different product? Did they respect the out-list? Dare they say no to the stack? Is ownership — DNS, code, content — clear? When the three answers are about the same work, you can talk commercial terms in the room. A scoreboard on three PDFs the document has not made the same is how you pick the bid that promised the most and cut the least.
If you have three bids and still cannot put them next to each other
Let us separate wish list, RFP and discovery.
Two pages of launch truths beat a 40-page PDF you cannot compare yourself.