VISUOSOFTS · WEB DEVELOPMENT
Choosing a software development partner on gut feel is how projects fail. The RFI (Request for Information) is the structured document that gathers comparable, honest information from potential vendors — before the RFP, before the commitment. This guide shows how to write one for software development.
Written for UK businesses procuring software: the RFI playbook.
WHAT THE RFI IS — INFORMATION, NOT PROPOSALS
The RFI gathers information: the vendor capabilities (the team, the experience — the factual), the approaches (the how — the indicative), and the fit signals (the relevant work, the references — the evidenced). It is not the RFP (the detailed proposal request) — it is the lighter, earlier step that builds the qualified shortlist the RFP will address.
The RFI's value: the comparable (the same questions — the apples-to-apples), the efficient (the lighter lift — the more vendors, the wider net), and the informed (the shortlist built on evidence, not marketing). The businesses that RFI first write better RFPs — the information shaping the detailed requirements. For the marketing strategy choice that parallels vendor selection, see push vs pull marketing.
WHEN TO USE IT — THE PROCUREMENT SEQUENCE
Use the RFI when: the vendor landscape is unclear (the many options — the narrowed), the requirements are emerging (the not-yet-RFP-ready — the informed), or the shortlist needs evidence (the claims — the verified). Skip it when: the vendor is known (the trusted — the direct), the project is small (the overhead — the disproportionate), or the RFP is ready (the requirements clear — the direct).
The sequence: the RFI (the information — the longlist to shortlist), the RFP (the proposals — the shortlist to preferred), the selection (the due diligence — the preferred to partner). Each stage filters; each stage deepens. The rushed procurement (the RFI skipped, the RFP vague) is the failed project's most common ancestor.
THE STRUCTURE — THE RFI DOCUMENT
Structure: the introduction (your business, the context — the oriented), the objectives (what you are trying to achieve — the outcomes, not the features), the scope indication (the project's shape — the sized), the questions (the structured — the comparable), the response format (the template — the enforced), and the timeline (the deadlines — the respected).
The structural disciplines: the concise (the 5–10 pages — the answered, not the dreaded), the focused (the questions that discriminate — the differentiating, not the generic), and the fair (the same for all — the comparable). The RFI should take the good vendor hours, not days, to answer — the response quality reflects the ask's quality.
THE QUESTIONS — WHAT TO ASK
Ask about: the company (the size, the history, the financials — the stable), the team (the who — the CVs, the relevant experience — the actual people), the relevant work (the similar projects — the evidenced, the referenced), the approach (the methodology, the tech stack — the how), and the commercial (the models, the indicative rates — the affordable).
The discriminating questions: the "describe a project like ours that went wrong and what you did" (the honesty — the revealing), the "who exactly would work on our project" (the bait-and-switch prevented), and the "what would you need from us to succeed" (the partnership — the mature). The generic questions ("describe your company") produce the generic answers; the specific, the revealing. Ten sharp questions beat thirty soft ones.
Probe the delivery reality, not just the sales story: the "show us the code repository structure of a similar project" (the craftsmanship — the evidenced), the "how do you handle scope changes mid-project" (the flexibility — the commercial honesty), and the "what happens when the lead developer leaves" (the continuity — the risk). The vendors' answers to the uncomfortable questions reveal the partnership you are actually buying. The RFI that avoids the hard questions produces the shortlist that avoids the hard truths — and the project pays for both.
EVALUATE RESPONSES — THE SHORTLIST
Evaluate: the scoring matrix (the criteria weighted — the objective), the evidence test (the claims verified — the references called, the work inspected), and the fit judgement (the cultural — the partnership, the communication).
The evaluation disciplines: the independent scoring first (the bias managed), the consensus discussion (the perspectives — the balanced), and the shortlist of three (the manageable — the deep-dive). The scoring informs; the judgement decides — the matrix is the tool, not the decider. The vendors who cannot answer the RFI well rarely deliver the project well — the response is the first deliverable.
Look beyond the scores for the signals: the responsiveness during the process (the communication preview — the partnership foretold), the questions they asked you (the curious vendor understands better — the engaged), and the honesty about fit (the "we're not ideal for X" — the trustworthy). The evaluation's hidden purpose is the relationship preview: the RFI process is the first project you run together, and how it goes predicts how the real one will. Run the RFI like the first project milestone — because it is. The delightful RFI experience rarely precedes the dreadful project.
WHAT COMES NEXT — FROM RFI TO PARTNER
Next: the RFP to the shortlist (the detailed — the informed by the RFI), the presentations (the chemistry — the met), the due diligence (the references, the financials — the verified), and the selection (the negotiated — the partnered).
Carry the RFI's learning forward: the requirements sharpened (the informed), the evaluation criteria refined (the evidenced), and the relationship started (the responsive vendors — the noted). Our application development team responds to RFIs regularly — the structured, the evidenced, the honest. Talk to us about your software project — the RFI answered properly, the partnership built to last.
WRITING AN RFI — FAQs
RFI vs RFP — what's the difference?
The RFI gathers information (the lighter — the shortlisting); the RFP requests proposals (the detailed — the selection). The RFI precedes the RFP where the landscape or requirements need the exploration first.
How many vendors should we send it to?
Six to ten for the RFI (the wide net, the manageable reading); three for the RFP (the deep dive). More vendors means more comparison but more evaluation work — the balance at the shortlistable.
How long should we give vendors to respond?
Two to three weeks — the respectful, the sufficient. Less rushes the quality; more loses the momentum. The timeline stated upfront, the deadline honoured.
Should we share the budget?
The indicative range helps enormously — the vendors self-selecting, the proposals realistic. The hidden budget produces the misaligned responses; the shared range produces the relevant ones.
What is the biggest RFI mistake?
The generic questionnaire that every vendor answers identically — the non-discriminating. The sharp, specific, revealing questions are the RFI's entire value; the generic is the wasted effort for everyone.
