How to write a software RFP that attracts good proposals

A good software request for proposals describes the problem you need solved, the outcomes that would count as success, and how responses will be judged — then leaves the solution design to the people bidding. The more precisely you prescribe features, platforms and screen counts, the more you narrow the field to vendors willing to price guesswork, and the more the strong ones quietly decline to bid. This guide covers what to put in, what to leave out, and how to read the answers that come back.

Why do prescriptive RFPs get worse proposals?

Weak RFPs tend to fail the same way: they specify the solution instead of the problem. Someone on staff, often working from a competitor's website or a vendor demo seen at a conference, writes out a long list of required features, a mandated technology stack and a page count. Vendors are then asked to price that list exactly as written.

Here is what happens next. The experienced firms read the list and see contradictions, missing pieces and choices they know will hurt the project — but the format gives them no room to say so. They either decline to bid or price in the risk of building something they believe is wrong. The less experienced firms simply say yes to everything and bid low, because saying yes costs nothing at proposal stage. Your process has now filtered for overconfidence and against honesty, which is the opposite of what an RFP is for.

A prescriptive RFP feels safer because it looks rigorous. In practice it transfers design decisions to the least qualified moment in the project: before anyone has examined your data, interviewed your users or seen your existing systems. Specify the destination and the constraints. Leave the route to the people who drive it for a living.

What belongs in an RFP: outcomes, context and constraints

Strong proposals are built on context, so give bidders the material to reason with. Describe your organisation and who the software serves: members, the public, staff, board, regulators. Explain what is broken or missing today, in plain language, with real examples. State the outcomes that would count as success a year after launch — renewals completed without staff intervention, applications processed in days rather than weeks, one source of truth for member records — described in terms of behaviour, not features.

Then state your genuine constraints. These are legitimate and vendors need them: legislation and privacy rules you must satisfy, accessibility obligations, official-languages requirements, systems the new software must talk to, procurement rules you cannot bend, and hard dates such as a renewal season or a legislated deadline. A constraint is something that is true whether or not the vendor likes it. A feature list is not a constraint; it is a first draft of someone else's job.

The difference is easiest to see side by side:

Should you tell vendors your budget?

Yes, as a range. Withholding the number is a common mistake among associations and public-sector teams, and it rests on a misunderstanding: that hiding the budget forces vendors to compete on price. What it actually does is force every bidder to guess your ambition level. Software scope is elastic — a member portal can be modest or elaborate, and both are defensible answers to the same RFP. Without a range, one vendor prices the modest version, another prices the elaborate one, and your evaluation committee ends up comparing proposals for two different projects.

An honest range does the opposite. It tells serious vendors what tier of solution to design, which makes their proposals comparable, and it lets them tell you early and candidly if your ambitions and your range do not match — which is information you want before contract, not after. If your range is genuinely fixed by a board motion or an approved appropriation, say so. If there is flexibility for the right case, say that too. You lose nothing: a proposal is not a final price, and every serious engagement still ends in negotiation.

The best proposals answer a problem you described honestly. The worst answer a specification you wrote to feel safe.

What evaluation criteria actually work?

Decide how you will score proposals before you open the first one, write the criteria into the RFP, and publish the weights. This is standard practice in government procurement for good reason: it keeps the evaluation defensible, and it tells vendors what you value so they can respond to it. A workable structure looks like this:

1. Understanding of the problem. Does the proposal restate your situation accurately and add insight you did not include, or does it echo your own words back?
2. Approach and plan. Is there a credible sequence of work with decision points, or a wall of methodology boilerplate?
3. Relevant evidence. Comparable projects, references you can actually phone, and named people who will do the work.
4. Working relationship. How the vendor communicates, demonstrates progress, and handles change — ask them to describe a real disagreement with a client and how it was resolved.
5. Price, weighted last and never alone. Score value against the approach offered, not the lowest number in the pile.

Keep the committee small and mixed: someone who owns the budget, someone who will administer the system daily, and someone who represents the end users. Score independently, then discuss. And leave room in the process for a conversation — a shortlist interview or working session tells you more about a vendor than any written response, because writing proposals is a skill distinct from building software.

What are the red flags in vendor answers?

Reading proposals is pattern recognition. These patterns should worry you:

• No questions during the bidding window. Any real project has ambiguities. A vendor who asks nothing is either not paying attention or planning to resolve every ambiguity in their own favour later, through change orders.
• Yes to everything. If nothing in your RFP prompted a caution, an alternative or a "here is the trade-off", you are reading sales copy, not analysis.
• A firm fixed price on a vague scope. Precision in the price without precision in the scope means the price is fiction, and the gap will surface as disputes.
• The team appears only after award. If the proposal names impressive senior people but the contract does not commit them, expect the work to be done by whoever is free.
• Ownership left unstated. Ask directly who owns the code, designs, data and accounts at the end. Hesitation here is the most expensive red flag on this list, because it compounds for years.
• Boilerplate that ignores you. If your organisation's name could be swapped for another and the proposal would still read the same, the project will be treated the same way.

None of these alone is disqualifying; together, two or three of them usually are. The mirror test also applies: if every proposal you received shows the same flags, the RFP itself may have invited them.

How OlDevs responds to RFPs, and how we can help you write one

OlDevs is a full-stack technology studio in Vancouver, working since 2014 with organisations across Canada, including the associations and government teams this article is written for. When we respond to an RFP, we do the things this guide asks you to look for: we ask questions, we flag trade-offs instead of agreeing with everything, we name the people who will do the work, and the contract puts all code, designs, accounts and IP in your name. Our delivery process is built around a working demo every week, so evaluation does not stop at the proposal — you see real progress from the first sprint, whether the project is a member-facing web application or a rebuild of an aging internal system.

We are also happy to help before the RFP exists. A short discovery engagement can turn a feature wish-list into an outcomes-based RFP with defensible evaluation criteria, and it does not oblige you to hire us for the build. Either way, we reply to every enquiry within one business day, in English or French. If you have a project taking shape, request a quote and tell us what you are trying to achieve — that, after all, is the whole idea.