A software RFP is supposed to make suppliers comparable. Most achieve the opposite, because they specify a solution in enough detail to constrain the answer while leaving out the information anybody would need to price it. The result is five quotes spanning an order of magnitude, all technically responsive, none of them measuring the same thing.

The usual diagnosis is that suppliers are being evasive. Occasionally true. Far more often the document asked for a number that could not be produced from what it contained, and each supplier filled the gaps with different assumptions.

The test for whether your RFP will work: could two different suppliers read it and arrive at meaningfully the same scope? If a document says “user management” with no indication of how many roles, whether permissions vary by record, or whether it integrates with an existing directory, one supplier prices a week and another prices two months. Both are answering honestly. You cannot compare them.

Why a Feature List Is the Wrong Starting Point

A list of features tells a supplier what you decided, not what you need. That matters because the decision may be wrong, and the supplier who spots it has no way to say so within the structure you have imposed.

It also hides the information that drives cost. Effort in software tracks the awkward parts: how many external systems you connect to, how much existing data must be migrated and how clean it is, how many distinct user types with different permissions, and what the compliance obligations are. A feature list can be long and contain none of that.

The alternative is not vagueness. Describe the problem precisely, state the constraints that are genuinely fixed, and let the proposal explain the approach. You will get answers that differ, and the differences will be informative rather than noise.

What a Software RFP Should Actually Contain

The business problem and what success means. What is happening now, what should happen instead, and how you will know it worked. Suppliers use this to challenge scope, which is the most valuable thing they can do at this stage.

Volumes and scale, with numbers. Users, transactions, records, expected growth. This alone eliminates a large share of quote variance.

Systems it must connect to, named, with a note on whether each has a documented API. A single legacy integration with no documentation can exceed the cost of everything else combined.

Data you already have. How much, where it lives, and what condition it is in. Migration is routinely the most underestimated line in any project.

Constraints that are genuinely fixed. Regulatory obligations, a mandated hosting location, an existing identity provider, an immovable date. Say which are hard and which are preferences, because suppliers price hard constraints defensively.

What you are not asking for. Explicitly excluding things is one of the cheapest ways to reduce variance between quotes.

Your budget range. Withholding it does not get you a lower price. It gets you proposals scoped for a budget nobody knows, which then have to be redone. A range lets suppliers tell you what is achievable inside it. Our custom software development cost guide covers what the bands buy.

The Questions That Separate Suppliers

Ask fewer, better questions. These reveal more than a hundred-row compliance matrix.

What would you build first, and why? Sequencing exposes whether they understood the problem or just the document.

What is the riskiest part of this and how would you reduce it? A supplier who names a real risk is more trustworthy than one who reports none.

Who specifically will do the work? Names, seniority and how much of their time. A proposal written by the people who will not build it is a familiar disappointment.

What happens when the scope changes? It will. The answer tells you how the relationship works under pressure, which matters more than the day rate.

What do you need from us? Projects fail on client-side availability at least as often as on supplier capability, and a supplier who says so is describing reality rather than selling.

What do we own at the end? Code, infrastructure, accounts, data. Get this in writing before selection rather than after.

Reading the Responses

The cheapest quote usually reflects the smallest interpretation of the scope, not the greatest efficiency, and the gap surfaces as change requests once work has started.

Look at where each supplier put its effort. A proposal that spends its length on the integration and the data migration has understood where the difficulty is. One that spends it on methodology and team photographs has not engaged with the problem.

Treat unasked-for challenges as a positive signal. A supplier who says part of your scope is unnecessary, or that a stated constraint will cost more than it is worth, is doing the job you actually want done. Suppliers who agree with everything are easier to read and worse to work with.

And check that every quote is answering the same question. Where two differ by a factor of three, one of them has assumed something the document did not say, and finding out which is more useful than any scoring matrix.

When Not to Run One

If the work is small, or exploratory, or you do not yet know what you need, an RFP is the wrong instrument. It costs both sides weeks and produces a false impression of precision.

For those, a paid discovery engagement is usually better: a short piece of work producing a specification you can then take to market, or that establishes the thing is not worth building. Either outcome beats a competitive process over a scope nobody could define. The scoping discipline in our MVP software development guide applies directly.

Mecanik responds to RFPs and also helps organisations write them, as part of our software development work. The documents that produce good quotes are consistently the shorter ones with real numbers in them.

Frequently Asked Questions

What should a software RFP include? The business problem and what success looks like, volumes and scale with actual numbers, named systems it must integrate with and whether each has a documented API, the condition of data to be migrated, which constraints are genuinely fixed, what is explicitly out of scope, and a budget range.

Should I put my budget in the RFP? Yes. Withholding it does not produce a lower price, it produces proposals scoped against a budget nobody knows, which then have to be redone. A stated range lets suppliers tell you what is realistically achievable within it and makes the responses comparable.

Why do quotes for the same software vary so widely? Usually because the document left gaps and each supplier filled them with different assumptions. A line such as “user management” with no indication of role count, per-record permissions or directory integration can honestly be priced at a week or at two months. The variance is a property of the RFP, not the suppliers.

What questions reveal a good software supplier? What they would build first and why, what they consider the riskiest part and how they would reduce it, who specifically will do the work and for how much of their time, how scope changes are handled, what they need from you, and what you own at the end.

When should I not use an RFP? When the work is small, exploratory, or you cannot yet define what you need. A competitive process over an undefined scope costs both sides weeks and creates false precision. A paid discovery engagement that produces a specification, or establishes the project is not worth doing, is the better instrument.