Websites
SMEs

How do I prepare a request for proposal for a website or app?

Before you ask anyone for quotes, write one document that answers seven questions: the goal, the users, the pages, the content, the languages, the deadline, and the budget range you set yourself. A good brief makes quotes comparable and separates a provider who reads your project from one who sends a stock template. This guide covers the questions, what a provider needs to quote honestly, the red flags in weak briefs, and ends with a fill-in template.

Key points

Write the brief before contacting any provider and send the same version to every candidate — that is what makes quotes comparable.
A good brief answers seven questions: goal, users, pages and features, content, languages, deadline, and budget range.
To quote honestly a provider needs a clear scope, ready assets, named integrations, and one person who decides.
Vague phrases like "professional website" produce vague quotes; every requirement should be verifiable at delivery.
Send the brief to three candidates at most, and compare scope, timeline, ownership and maintenance before price.

Why each question matters

The table sums up the seven questions and what happens when one is left blank.

The question	Why it matters to the provider	What happens if it stays blank	How to answer it
What should the website achieve?	It steers features and design before any technical discussion	A quote built on looks rather than results	One main goal with a measurable outcome over 12 months
Who will use the website?	It sets the structure, the interface and the visitor’s path	An interface "for everyone" that fits no one	Describe your real customer: who they are, what they want, on which device
Which pages and features?	It fixes the volume of work and separates must-have from later	Quotes with scopes that cannot be compared	A list of pages and features, each marked essential or phase two
Who prepares the content and visuals?	Writing and production get quoted instead of appearing as surprise costs	A delayed launch because the copy is not ready	For each asset: ready, to be written, or to be bought
Which languages?	It multiplies content pages and sets RTL handling and URLs	An Arabic site built in one language, then rebuilt	Name the languages and who approves the final translation
What is the deadline?	It lets the provider prioritise honestly	A promise of an impossible date, or no date at all	State the desired launch date and why it matters
What is the budget range?	It helps the provider propose something within your reach	Scattered quotes that do not help you choose	Set a range yourself; it is your decision, not the provider’s

Why write the document before asking about prices

The common mistake is starting with "how much does a website cost?" before describing the website. The question without a description has no honest answer: two projects both called "a website" can differ completely — a five-page brochure site is not an online store with payments and stock management.

The brief forces you to settle your decisions before the first provider walks in, then goes out in the same version to every candidate. That is what makes comparison possible: quotes built on the same description. France Num, the French government’s programme for small businesses, lists four direct benefits: it clarifies your goals, lets you compare offers, serves as a project steering tool, and becomes the contractual reference if a dispute arises.

The document does not need to be technical: five to ten well-structured pages are enough for a simple website or app.
Write it yourself first, then send it to the candidates; do not let each provider hand you a different questionnaire.

The seven questions your brief must answer

Any good brief answers seven questions, and needs no more to start. First, the goal: one main goal with a measurable outcome — say, doubling contact requests within a year — beats three vague sentences. Second, the users: describe your actual customer, not an imaginary audience. Third, the pages and features: mark each item essential or phase two, because that separation is what keeps quotes comparable when the budget forces trade-offs.

Fourth, the content: who writes, who photographs, who reviews? Fifth, the languages: a second language means a bilingual structure and translation management. Sixth, the deadline: a desired launch date with the reason for the timing. Seventh, the budget range, which is your decision: set it yourself, because a provider who knows your limits proposes something achievable instead of a wish.

Goal: a measurable outcome within a set period.
Users: who they are, what they want, on which device.
Pages and features: a list, each item marked essential or deferred.
Content: who writes, who produces the visuals, who approves.
Languages: how many, and who approves the translation.
Deadline: the desired launch date.
Budget: an approximate range you decide.

What a provider needs to quote honestly

An honest quote is not a number tossed into an email; it is the result of reading your description. A serious provider builds a quote on a clear scope, assets that are ready or whose source is known (logo, images, copy, domain name), named integrations (payments, email, booking), and post-launch expectations (maintenance, updates, backups). Any of these you leave vague shows up in quotes as a safety margin — or does not show up at all and surprises you later.

The Government Performance Lab’s RFP template for US governments recommends a scope that is clear, specific and realistic, and mentions budget information because it helps proposers right-size their answers. The international engineering standard for requirements, ISO/IEC/IEEE 29148, defines what makes a requirement good: unambiguous and verifiable. Write every line of your brief so that its delivery can be checked, not interpreted.

Attach links to websites you like, with one line on what you like in each.
Name the systems the project must connect to: payments, email, booking, any tool you already run.
Say who will manage content after launch and how many people.
State your maintenance expectations: update frequency, backups, and who owns the code and the accounts.

Red flags in a weak brief

Red flags describe the brief, not the provider. A document full of "professional website" and "modern design" with not one example signals that nothing has been decided, and the quote will be built on guesswork. A brief that asks for the price before any description selects whichever provider throws the lowest number. A brief with no deadline lets your project be pushed behind every other one.

In the other direction, ask the provider for proof of seriousness: delivered projects of a similar kind, the name of the team that will actually work on your project, and a staged plan with verifiable deliverables. The City of Portland’s RFP guide makes the point that evaluation does not rest on price alone but on criteria announced from the start; write into your brief how you will compare offers, so every candidate sees the same rules.

Vague phrases with no examples or measures: "professional", "modern", "top quality".
Asking for the price before describing the project.
No deadline, or no single person in charge of the decision.
Hidden features that surface in follow-up questions and were never in the document.
A quote that does not separate scope, timeline, ownership and maintenance.

A template to copy and fill in

Copy the points below into a file and complete them before you send anything out. Leave no point empty; if you do not know the answer, write "not decided, proposals welcome" — a good provider will propose and justify the proposal.

1. Who we are: the business in two lines, and who will decide on this project.
2. Goal: what must the website or app achieve over 12 months, and how will we measure it?
3. Users: who is the primary customer, what do they want, on which device?
4. What exists today: is there a current site or page? What do we keep, what do we replace?
5. Pages: the list of pages, each marked essential or phase two.
6. Features: contact form, booking, store and payments, customer account, search, blog... each marked the same way.
7. Content: copy, images, video, logo — ready, to be written, or to be bought, and who approves the final version.
8. Languages: which languages, and who approves the translation.
9. Integrations: payments, email, booking — every system to connect, by name.
10. After launch: updates, backups, full ownership of the code, the design and the accounts.
11. Deadline: the desired launch date and the reason for the timing.
12. Budget: an approximate range you set; the provider is not asked to set it for you.
13. References: links to websites or apps you like, with one line per link.
14. Response window: the date offers are due and the channel for questions.

How to compare offers once they arrive

Compare before price: scope covered, staged timeline, ownership, maintenance, then price. Two quotes with the same figure can differ because one excludes copywriting or a year of maintenance. The Harvard template recommends leaving several weeks for offers and questions; if you rush the provider, you rush the quality of their reading of your project.

Send the document to three candidates at most: beyond that, the comparison blurs and everyone loses time. Ask each candidate to point out explicitly the unclear parts of your brief; the questions they ask reveal what your document is missing, and you can fix it and resend the same version to everyone.

Frequently asked questions

Should I state the budget or hide it?

State it as an approximate range you set. Hiding it does not protect you: every provider guesses your limits and the quotes scatter, impossible to compare. The exact figure is not what is being asked at this stage — the project is quoted against the scope described in the document.

How long should the document be?

For an ordinary website or app, five to ten well-structured pages are enough, as the European small-business references advise. More important than length: every point should answer a specific question and stay verifiable.

One provider or several?

Three at most, with the same document. Beyond that, the comparison blurs and everyone loses time.

What if I do not know the number of pages or features yet?

Write down what you know, mark the rest phase two, and leave no point empty: note "not decided, proposals welcome". A provider who reads your brief will ask questions that show you what is missing.

Does this apply to an app too?

Yes — the structure is the same: goal, users, main screens, content, languages, integrations, deadline, budget. An app adds two points: the target operating system (Android, iOS, or both) and the store publishing requirements.

Who owns the website after launch?

Ask in the document for full ownership of the code, the design, the accounts and the domain in your company’s name, written into the delivery clause. This is agreed before work starts, not after.

Where to go next

Ask us to build your website or appGo to the service page.Get your current website checked before you decideGo to the service page.Digital marketing after launchGo to the service page.