RFP Best Practices: A Complete Guide to the Vendor Selection Process

Many RFPs go wrong before a single vendor reads them. They describe a solution instead of a problem, hide the budget and ask dozens of questions nobody will score. What comes back is a stack of generic proposals that are hard to compare. This guide covers RFP best practices for software development, written from the other side of the table: by a software house that reads and answers RFPs for a living.

Key takeaways

• Describe the problem, not the solution. Vendors propose better approaches when they understand the "why".
• Share a budget range. Without one, proposals can't be compared.
• Send the RFP to no more than 3–5 qualified vendors.
• Set evaluation criteria and weights before you open proposals, and weigh technical factors above price.
• Ask for evidence, not declarations: code samples, a named team, scenario answers.
• Flag accessibility (WCAG) and other non-functional requirements upfront.
• Choose the contract model based on scope certainty, and ask each vendor how change will be handled.

RFP best practices for software development projects

Software development isn't like buying off-the-shelf products, and neither are good RFP best practices. First, you're not buying a product. You're buying a team and a way of working. The RFP has to test how a vendor thinks, not just whether it can tick off a feature list. Second, scope moves. Requirements mature once users see working software, so an RFP that treats the specification as final leads either to inflated buffers now or painful change requests later.

Third, risk compounds. IT projects are unusually prone to extreme overruns: in How Big Things Get Done, Flyvbjerg and Gardner report that 18% of IT projects overrun by more than 50%, averaging 447% in that group. Oxford research points to interdependencies between technical components: a problem in one part can set off a chain reaction in the others. That's why an effective RFP process for complex projects asks about architecture, integrations and existing systems, not only features.

What is an RFP and where does it fit in vendor selection?

A request for proposal (RFP) is a formal document that invites potential vendors to explain how they would solve a specific problem, and at what cost. An RFI (request for information) maps the market, and an RFQ (request for quotation) prices something already clearly defined.

For custom software development, the RFP is almost always the right choice, because there's no catalogue price for a product that doesn't exist yet. In a typical selection process, it comes after market research and an optional RFI, and before shortlist demos, due diligence and contract negotiation.

Before you write the RFP: preparation best practices

Frame the problem, not the solution

The most common RFP mistake happens before the first page is written: the document describes a solution instead of a problem. The UK Government's Service Manual gives a neat example. The problem isn't building an interactive map of contact centres. It's making it easier for people to find their nearest centre when they need a face-to-face appointment. The same applies to digital products. "Build a mobile app with a loyalty module" closes the door on better ideas; "increase repeat purchases among existing customers" opens it.

Align key stakeholders early

Run short stakeholder interviews with the people who will use, pay for and maintain the product: department heads, IT and operations. Agree on must-haves versus nice-to-haves, and name one person who owns the final decision. Vendors can tell when an RFP was written by committee, and they price in that uncertainty.

Consider a paid discovery first

If the project scope is still fuzzy, don't force it into an RFP. Former 18F guidance recommends breaking large, monolithic projects into smaller, incremental pieces. A short paid discovery turns assumptions into project requirements and gives you a realistic timeline to put in the RFP.

How to write an RFP vendors can answer well

A well written RFP document isn't a long one.

Keep it short and specific

When 18F, a former US government digital services team, bought software development, it set strict page limits and reviewed vendors' actual source code, not just their claims. If you start from an RFP template, cut every question you won't actually score.

Share a budget range

Without a budget, every vendor guesses, and you end up comparing a lean MVP with a full platform. A range doesn't weaken your negotiating position. It's what makes quality proposals comparable.

Ask scenario questions

"Describe your experience with integrations" invites marketing copy. "How would you migrate 200,000 user accounts from our legacy system without downtime?" invites thinking. Scenario-based RFP requirements are the fastest way to separate real technical capabilities from polished sales copy.

Run a structured Q&A

Set one deadline for questions and share every answer with all vendors. It cuts back and forth clarifications and keeps the process fair.

Set a realistic timeline

Include the proposal deadline, submission instructions and a decision date. With a tight process, a technology selection can move from shortlist to decision in 6–8 weeks. Unrealistic deadlines don't speed things up. They filter out the vendors who plan carefully.

RFP evaluation criteria and scoring

Decide how you'll score proposals before you open the first one. Criteria written after reading the bids tend to reward the vendor who impressed you most, not the one who fits best. Predefined criteria keep the evaluation process honest.

Many guides put price first. For software development, that's backwards. When 18F evaluated development vendors, technical approach, staffing approach and similar experience together counted for significantly more than price. The logic is simple: a cheaper team that builds the wrong thing is the most expensive option you have.

For RFP weighted scoring, give the most weight to the technical approach: how well it fits your problem and how honestly it names the risks. Next comes the proposed team (named people, not just roles), then similar projects with references you can actually check. Price comes fourth, judged on a clear breakdown and stated assumptions, and collaboration fit last.

Adjust the weights to your project, but lock them once proposals arrive. When evaluating proposals, have each person score independently before the group discusses.

Tip from the other side of the table: what makes a software house give an RFP its best answer

Here's something buyers rarely consider: vendors choose RFPs too. On average, response teams answer 55% of the RFPs they receive and spend around 33 hours on each one. A weak RFP doesn't get a weak answer from the most qualified vendors. Often, it gets no answer at all.

So what makes an RFP stand out from our side of the table?

The RFPs I want to answer well start with a business problem and say what success looks like, not just a feature list. The client doesn't need every answer upfront: openness to define the rest together tells us they want a technology partner, not an order-taker.

Magdalena Dąbrowska IT Delivery Manager at Miquido

Motivation is only half the story. The other half is what the development team needs to know upfront, from architecture and integrations to requirements that are easy to overlook.

One thing worth looking at from the start is accessibility, which is often pushed to the very end of a project. That's risky: added late, with little time left, it can turn a whole module upside down, and some features become far more complex once WCAG comes in. So it's worth checking early whether the design accounts for WCAG requirements, because they need to be built in at the design stage. Otherwise, accessibility will have to be added later through separately priced change requests.

Robert Jedynasty Flutter Developer at Miquido

It's also the law now: the European Accessibility Act has applied to many digital services in the EU since June 2025.

Magdalena also points to context about the users, known integrations (or the problems behind them), time and budget constraints, and features ranked from must-have to nice-to-have. It shows the client is ready to ship a leaner first release and learn from real users. Early design sketches help too, if the vendor is invited to review them with fresh eyes. 

Getting these aspects right leads directly to higher-quality proposals from the most suitable vendors.

Let’s talk about your project

Planning a software project? Tell us about the problem you want to solve, with or without an RFP. We'll come back with the questions that matter and an honest view of how we'd approach it. Talk to our team.

Top AI innovations delivered monthly!

The administrator of your personal data is Miquido sp. z o.o. sp.k., with its ... registered office in Kraków at Zabłocie 43A, 30 - 701. We process the provided information in order to send you a newsletter. The basis for processing of your data is your consent and Miquido’s legitimate interest.You may withdraw your consent at any time by contacting us at marketing@miquido.com. You have the right to object, the right to access your data, the right to request rectification, deletion or restriction of data processing. For detailed information on the processing of your personal data, please see Privacy Policy.

Show more