In short
- Describe the problem and the goal, not a ready-made solution - the vendor should propose how to solve it.
- List the users, the scope (must-have vs optional), platforms and integrations.
- State the constraints: deadline, budget (at least a range) and requirements such as GDPR.
- Ask for offers in a set structure - then the replies can be compared.
- Two to four pages are enough. The details come out in the conversation anyway.
Why write an RFP if there will be a call anyway
A request like "we need an ordering app, how much is it?" produces offers you cannot compare: every vendor guesses a different scope, so prices differ several times over and nobody knows why.
A short document with the goal, the users and the scope fixes that. Vendors price the same thing, ask specific questions, and the first call is shorter and more useful.
What the request must include
- Company context: what you do, how many people you employ, which systems you use (ERP, CRM, email).
- Goal and problem: what does not work today, what it costs (time, errors, delays) and how you will know the project worked.
- Users and roles: who will use the system (staff, customers, partners), how many and what each role can do.
- Scope: a feature list split into must-haves for the first version and things that can wait.
- Platforms: browser, phone (iOS, Android), desktop, tablet in the field. Whether the app must work offline.
- Integrations: which systems the app exchanges data with, in which direction, how often, and whether they have an API.
- Data and migration: which data has to be moved from current tools and how much there is.
- Constraints: deadline (and what drives it), budget or a range, legal and security requirements.
- What you expect from the offer: structure, billing model, schedule, warranty, handover of code and copyright.
If you do not know something, say so. "We do not know whether our ERP has the API we need" is better than a guess - a good vendor will help you check.
Describe the problem, not a ready-made solution
The most common mistake is a request that prescribes the solution: "an Android app with a 12-field form". You then get exactly that - even if a simpler solution would do more for less.
Describe the situation instead: "drivers fill in paper delivery reports, the office retypes them into the ERP two days later and 10% need follow-up". From that, a vendor can propose several options and say which makes most sense.
What to leave out
- Passwords, access keys and login details.
- Personal data of customers and employees - examples without names are enough to describe a process.
- Trade secrets. If the project cannot be described without them, sign a non-disclosure agreement first.
How to compare offers
The lowest price rarely means the cheapest project. When comparing, look at:
- Whether the vendor understood the problem - and asked questions. No questions on an incomplete request is a bad sign.
- Scope: what is included and what is priced separately or left out (testing, deployment, training, data migration).
- Billing model: a fixed price for a fixed scope, or hours worked against an estimate.
- Stages and schedule: when you will see working parts, not just the final date.
- Who will work on the project and whether testing (QA) is part of the team.
- Source code and copyright: whether and when they pass to you.
- Warranty, response time for bugs and maintenance after launch.
Common mistakes
- A one-sentence scope or, the opposite, a 40-page specification nobody reads.
- No information about integrations - they change the estimate most often.
- Hiding the budget. A range lets the vendor propose a scope that fits it.
- Sending the request to a dozen companies. Three to five well-chosen ones and time to talk to each work better.