A good software development RFP has nine sections: company context, the business problem, current systems and integrations, scope with explicit exclusions, non-functional requirements, constraints on timeline and budget, what you expect in the response, the evaluation criteria with weights, and the process timeline. Give vendors three to four weeks, hold a questions call, and score every response against the published criteria. The commonest mistake is a 40-page feature list with no problem statement, which produces incomparable quotes.
Prices are in US dollars. Euro and pound figures in parentheses are approximate, rounded conversions. Quotes are issued in the currency of your contract.
A request for proposal is the document that decides what kind of proposals you get back. A vague one produces five quotes that cannot be compared and a selection made on price. A precise one produces proposals that answer the same questions in the same order, which is the only way a procurement committee can choose well. This post is for the CIO, head of operations or program manager who has to write one for a custom build, a modernization or an integration program. It gives you the section template, the timeline, the scoring method and the things to leave out.
What should a software development RFP contain?
The table below is the template we wish every RFP followed. Each section has one job, and the common mistake column is drawn from the RFPs we have answered over the years.
| Section | What to include | Common mistake |
|---|---|---|
| 1. Company context | Who you are, size, industry, the department sponsoring the work, who will use the software and how many of them. | Three pages of corporate history and no mention of the users. |
| 2. The business problem | What is slow, expensive or risky today, measured where possible. What changes for the business if it is fixed. | Skipping this and starting with a feature list. Vendors then quote the list, not the outcome. |
| 3. Current systems | The systems the new software must talk to (ERP, CRM, identity provider, data warehouse), their versions, and whether they have documented APIs. | Listing them by brand name only. "Integrates with SAP" can mean a week or six months. |
| 4. Scope and exclusions | The user roles, the core journeys, the must-have capabilities, and a clear list of what is out of scope for this phase. | No exclusions. Every vendor assumes a different boundary and the quotes vary by a factor of three. |
| 5. Non-functional requirements | Expected users and load, uptime, security and compliance obligations, data residency, accessibility, supported browsers and devices. | Copying a generic list with "99.999 percent uptime" that nobody has budgeted for. |
| 6. Constraints | Target go-live, budget range or ceiling, procurement rules, preferred technologies if any, and why. | Hiding the budget. Vendors cannot propose a sensible phasing without it. |
| 7. Response requirements | The structure every proposal must follow, page limits, the team CVs you want, references, and a pricing template. | Leaving the format open, which guarantees incomparable responses. |
| 8. Evaluation criteria | The criteria and their weights, published in the RFP. | Keeping weights secret, then being surprised that every vendor leads with price. |
| 9. Process and timeline | Questions deadline, answers published to all, submission date, shortlist date, presentations, decision date, contract start. | A ten-day deadline. The vendors you want are busy and will decline. |
How do you describe the problem so vendors can scope it?
Write the business problem as a short narrative, then a list of measurable pains. "Order processing takes four days because three teams re-key data between the ERP, a shared spreadsheet and the courier portal. Errors are caught by the customer. We lose an estimated two percent of orders to this." That paragraph tells a competent vendor more than fifty feature rows do. It lets them propose an integration instead of a new screen, or a phased delivery that fixes the worst step first.
Then list the user roles and what each must be able to do, as journeys rather than features. "A warehouse supervisor must be able to see today's exceptions and resolve each one in under a minute" is a journey. "Exception dashboard" is a feature that every vendor will read differently. If you have a discovery report already, attach it. If you do not, say so, and ask vendors to price a discovery phase separately. The discovery phase for enterprise software explains what that phase should produce.
Should you state the budget?
Yes, as a range or a ceiling. The fear is that every vendor will quote the ceiling. In practice, a published range does three useful things: it removes the vendors who cannot work at that level, it lets serious vendors propose a phasing that fits, and it exposes the vendor who quotes far below it, who has either misread the scope or plans to recover the difference through change requests. How much enterprise software development costs gives you the bands to set a realistic range: $80,000 to $200,000 (€70,000 to €175,000, £60,000 to £150,000) for a departmental tool, $200,000 to $600,000 (€175,000 to €520,000, £150,000 to £445,000) for a core platform with several integrations, and $600,000 to $2,000,000+ (€520,000 to €1,740,000+, £445,000 to £1,480,000+) for an enterprise-wide program delivered in phases.
How long should you give vendors?
- Three to four weeks from issue to submission for a build or modernization of any size. Two weeks produces rushed proposals from whoever was free.
- A questions window of seven to ten days, with every question and answer published to all bidders. Unequal information produces unequal proposals.
- One clarification call per vendor, thirty minutes, before submission. The quality of the questions a vendor asks on that call is one of your best signals.
- Two weeks for evaluation and shortlisting, then presentations from two or three finalists, then reference calls, then a decision. Six to eight weeks end to end is normal for a program above $200,000 (€175,000, £150,000).
How do you score the responses?
Publish the weights in the RFP and score against them with at least three evaluators, independently, before you discuss. A weighting that has worked well for custom builds:
| Criterion | Weight | What you are looking for |
|---|---|---|
| Understanding of the problem | 20 percent | They restate the problem in their own words and challenge something in your scope. |
| Approach and phasing | 20 percent | A first release that delivers value early, a plan for integrations and data, incremental rather than big bang. |
| Team and relevant experience | 20 percent | Named people, comparable projects, references you can call. |
| Price and commercial terms | 20 percent | Completeness of the price, not its size. Discovery, design, testing, deployment, support and ownership all present. |
| Risk, security and compliance | 10 percent | Specific answers to your non-functional requirements. See security questions to ask a vendor. |
| Support and exit | 10 percent | What happens after go-live, SLA options, and how you would leave them if you had to. |
Score price last. Evaluators who see the price first anchor everything else to it. And compare what each price includes before comparing the totals. How to read a software development quote lists the lines that are usually missing from the cheapest one.
What should you leave out?
- A prescribed technology stack, unless you have a real constraint such as an existing platform team. Prescribing the stack removes the vendor's best judgment and attracts vendors who say yes to everything.
- A fixed price demand before discovery. You will get either a padded number or a low one with a change-request strategy behind it. Ask for a fixed price for discovery and a priced estimate for the build, to be confirmed after discovery. Fixed price vs time and materials covers the trade-off.
- Hundreds of yes/no compliance rows copied from a template. Keep the ones that are real obligations for your organization and ask for evidence on those.
- Screens you have already designed. Attach them as reference, but do not make them the scope. They encode assumptions a good vendor should be allowed to question.
- Twenty-page legal terms as a precondition. Share the MSA and ask for exceptions in the response. MSA, SOW and change requests explains what each document should carry.
What does a strong response look like?
It follows your structure. It restates the problem and tells you something you did not want to hear about the scope. It proposes a first release that solves the most painful step inside the first few months. It names the people who will do the work, not the people who sold it. It prices discovery, design, build, testing, deployment and a support period as separate lines. It explains how your data and integrations will be handled, and it says what you will own at the end. How to choose an enterprise software development company turns those signals into a scorecard you can use in the presentations.
RFP checklist
- Problem statement with measured pains, before any feature list.
- User roles and journeys, not screens.
- Current systems with versions and API status.
- Explicit exclusions for this phase.
- Budget range and target go-live.
- Mandatory response structure and pricing template.
- Published evaluation weights.
- Three to four weeks to respond, questions shared with all.
How 7L responds to RFPs
7L International is a custom software development and digital transformation firm with business hubs in New York, London and Athens. We have answered RFPs for more than a decade and we decline the ones that cannot be scoped from the document, because a guess dressed as a proposal helps nobody. When we respond, we restate the problem, propose a phased delivery that puts a working slice in front of users early, price discovery separately, and name the team. If you are drafting an RFP and want a second pair of eyes on it before it goes out, or want to understand what enterprise software development with us looks like end to end, get in touch and we will tell you what a vendor would need to see.
Frequently asked questions
How long should a software development RFP be?
Ten to twenty pages is enough for most custom builds, including appendices. The problem statement, user journeys, current systems, exclusions and non-functional requirements carry the weight. Anything beyond that, such as long feature inventories or generic compliance matrices, tends to reduce the quality of responses rather than improve it.
Should we run an RFI before the RFP?
Run a short RFI when you do not know the market, for example when you are unsure whether to build, buy or customize an existing platform. A two-page RFI with a one-week response window tells you who is credible and what approaches exist. Then write the RFP with that knowledge. For a well-understood custom build, go straight to the RFP.
How many vendors should we invite?
Five to seven for an open RFP, three to four for an invited one. More than that and the evaluation burden exceeds the benefit, and good vendors decline RFPs with long bidder lists because the odds are poor. Shortlist two or three for presentations and reference calls.
Should the RFP ask for a fixed price?
Ask for a fixed price for the discovery phase and a priced estimate for the build, with the build price confirmed in writing at the end of discovery. Demanding a fixed build price from an RFP alone produces either a padded number or a low one that is recovered through change requests. If procurement rules require a single number, ask vendors to state their assumptions and the price of a change explicitly.
What is the biggest mistake in software RFPs?
Leading with a feature list instead of a problem statement. Vendors then quote the features as written, nobody questions whether they are the right ones, and the organization buys a faithful copy of its current process. A clear problem, the users and the measurable pains let a good vendor propose something better than what you asked for.