Contents
A good RFP describes the context, measurable goals, users, expected scope, technical constraints, a budget range and selection criteria. For a business app at $6,800 to $22,400 (€6,000–€20,000)excl. VAT, 5 to 10 pages are enough; sharing the budget is what makes the answers comparable.
A well-written RFP saves everyone time: it produces comparable quotes, screens out unsuitable providers and prepares the scoping phase. A vague RFP does the opposite: answers you cannot compare, prices that vary fivefold, and a decision made by chance. Here is the structure I recommend for a business application.
A template outline
| Section | Content | Indicative length |
|---|---|---|
| 1. Context | Your company, your business, your current tools | Half a page |
| 2. Goals | What the app should change, with measurable indicators | Half a page |
| 3. Users | Profiles, number, context of use (office, field, mobile) | Half a page |
| 4. Scope | Processes to cover, must-have features, nice-to-have features | Two to four pages |
| 5. Constraints | Tools to connect, data to migrate, security, hosting | One page |
| 6. Budget and timeline | Budget range, target go-live date | A few lines |
| 7. Response requirements | Format, content, deadline, selection criteria | Half a page |
For a business app at $6,800 to $22,400 (€6,000–€20,000)excl. VAT, five to ten pages are enough. Beyond that, you spend time describing details that are better handled during scoping.
The sections that make the difference
Measurable goals. “Modernize order management” guides nobody. “Process an order in under 5 minutes instead of 20, and stop re-entering data in the invoicing software” lets the provider propose the right solution, and lets you measure the result.
Scope in two columns. Separate what is essential for the first version from what you would like later. This lets you compare quotes on the same basis and plan the next steps in batches.
Connections and data. List every tool to connect (ERP, accounting, website, online store) and the data to migrate, with its volume. These are the items that make quotes vary the most.
Budget. Give a range. A serious provider will tell you whether it is realistic for the requested scope, which is useful information in itself. To size it before writing, the estimator gives an order of magnitude in one minute.
What to ask for in the responses
To be able to compare, require a common response format:
- A statement of understanding: your need restated by the provider, with their questions.
- The method: scoping, mockups, batches, testing, go-live.
- A detailed quote by batch, with assumptions and exclusions.
- A schedule with intermediate deliveries.
- Comparable references that can be seen in production.
- Terms: code ownership, hosting, support, maintenance; see what to require on code ownership.
The scoring grid
Set the criteria and their weights before reading the responses. An example grid, to adapt to your priorities:
| Criterion | Weight |
|---|---|
| Understanding of the need and fit of the solution | 30% |
| Method and schedule | 20% |
| Price and clarity of the quote | 20% |
| References and comparable experience | 15% |
| Terms: ownership, reversibility, maintenance | 15% |
Price matters, but rarely at more than 20 to 30%: a low quote based on a misunderstood scope ends up costing more. The other selection criteria are covered in how to choose a development partner.
The most common mistakes
- Sending the RFP to ten providers. Three or four well-chosen candidates give better answers.
- Describing the solution instead of the problem. Let providers make proposals; describe your processes and pain points.
- Leaving users out. An app designed without them will be poorly adopted.
- Demanding a firm commitment without scoping. The fixed quote comes after scoping; at RFP stage, a reasoned range is more honest.
- Not allowing time for questions. A meeting or a written Q&A session clearly improves the quality of the responses.
When an RFP is not necessary
For a project worth a few thousand euros, a formal RFP often costs more time than it saves. A two-page needs document sent to two or three providers is enough. If you are a French public buyer, the rules of the Code de la commande publique apply: this page does not cover them and does not replace advice from a public procurement specialist.
Where to start
- Bring future users together for an hour to list pain points and goals.
- Write the document using the outline above, staying focused on the need.
- Send it to three or four providers, with a Q&A date and a deadline.
If you would like to consult me, the 30-minute discovery call is free, and my services are described on the business apps page. The guide on writing an app requirements document will then help with the scoping phase.
Frequently asked questions
Should we state our budget in the RFP?
Yes, at least as a range. Without a budget, providers answer with very different scopes and the quotes can no longer be compared. With a range, each one proposes the best they can deliver for that amount.
How long should providers have to respond?
Two to three weeks for a mid-sized project, with a Q&A period at the start. Too short a deadline encourages generic answers; too long and the project loses momentum.
Is a private company required to run a formal tender?
In France, a private company is free to choose its provider, unless its own internal rules or a specific situation say otherwise. Public buyers are subject to public procurement rules (the French Code de la commande publique), which this page does not cover.
Do we need a detailed specification or a needs document?
For an RFP, a needs document focused on goals and processes is often enough. The detailed, screen-by-screen specification is then built with the chosen provider during scoping.
Can we ask candidates for a free mockup?
It is not advisable. A serious mockup takes several days of work; providers who agree to do it for free will do it quickly, without knowing your business. Ask instead for a demo of existing projects and a written restatement of your need.