How to Write a Software RFP

This guide is for anyone commissioning custom software who needs to put a project out to multiple vendors and compare the responses fairly. By the end, you will have a structure for the document, a clear sense of what to include and what to leave for conversation, and an understanding of why most RFPs produce padded, defensive quotes. It also covers how to write one that produces useful responses instead.

Who This Guide Is For

Procurement leads, founders, COOs, and project owners running a competitive process to select a software development partner for a defined piece of work. This is most useful when you have already done the internal scoping and now need to take a brief to market. It is not the right format for early-stage exploration. If you are still figuring out whether to build at all, a discovery conversation is faster and cheaper than a multi-vendor process.

Before You Start

You should already have a working scope document covering, at minimum, a description of the problem, the users, the core workflows, and the rough budget envelope. If you do not, How to Scope an Internal Software Project covers how to produce one. Going to market without a scope produces RFP responses that are essentially guesses, and the cheapest guess wins for the wrong reasons.

You should also have decided how many vendors to invite. Three to five is the sweet spot. Two is not enough comparison. Eight is more work to evaluate than the procurement saving is worth, and serious vendors will deprioritise an eight-way bid because the odds of winning are low.

Step 1: Be Honest About What the RFP Is For

Before drafting, decide what you want from this process. There are three legitimate reasons to run an RFP: to compare prices for work you have already defined, to compare approaches when you are not sure how to solve the problem, or to pressure-test a preferred vendor against the market. Each requires a different document.

If you are price-comparing, the scope must be tight enough that quotes are comparable. If you are comparing approaches, the document should describe the problem and let vendors propose how to solve it. If you are pressure-testing, be honest that you have a preference. Running a fake competitive process wastes everyone’s time and produces responses with no real engagement because experienced vendors can spot a shortlist of one.

The RFP that tries to do all three at once produces the worst of all worlds: scope tight enough to discourage creative responses, but loose enough that quotes are not really comparable.

Step 2: Write a Scope Statement That Is Actually Useful

The scope statement is the single most important section. A weak scope statement looks like this: “We need a client portal that lets our clients view their projects and communicate with us. It should be modern, secure, and easy to use.”

That paragraph is useless to a developer trying to quote. “Modern” is not a requirement; “easy to use” is not a feature; “client portal” covers a thirty-thousand-pound build and a three-hundred-thousand-pound one.

A strong scope statement for the same project: “We need a client-facing web portal where our 120 active clients can log in, view a list of their current projects with status, request a video upload, message their account manager via threaded comments per project, and download deliverables. The portal connects to our existing Airtable workspace for project data and Stripe for invoicing. SSO via Google Workspace is required. We need it deployed to a sub-domain of our main site, with our brand applied. Phase one excludes file management beyond download, calendar booking, and any client-side analytics.”

The strong version names the user count, the core actions, the integrations, the deployment expectations, and what is excluded. A vendor can quote it. The weak version requires three meetings before anyone can quote, and the quotes that come back will be padded with risk.

Step 3: Lay Out the Document in the Order Vendors Read It

A long RFP that buries the scope on page seventeen gets a shallow response. Vendors triage in the order they read, and the first few sections decide whether the bid gets serious attention. Order the document accordingly:

1. Project summary: three to four paragraphs, a non-technical reader can understand
2. Scope: what the system does and explicitly does not do
3. Users and workflows: who uses it, what they do
4. Technical context: existing systems, integrations, hosting, language preferences if any
5. Commercial terms: budget band, payment schedule, IP ownership, contract type
6. Timeline: when you want to start, when you need it live
7. Evaluation criteria: how you will compare responses
8. Required response format: what they should send back, by when
9. Background on your business and team: last, because it does not affect their estimate

The mistake is to put your company background and the project rationale first. Vendors care about it eventually, but not when they are deciding whether to bid.

Step 4: State the Budget — and Hold the Line

Most RFPs refuse to state the budget on the theory that disclosing it will inflate the quotes. In practice, hiding the budget produces three responses: one absurdly under the budget that cannot deliver, one absurdly over, and one in the middle that happens to be close. All three are noise.

The honest approach: state a budget band. “Our budget for phase one is in the band of £40,000–£70,000 depending on the approach taken.” This tells vendors whether to bid at all, lets them propose a scope that fits, and prevents the wasted effort of a £150,000 response when you have £50,000.

If you do not know the budget, say that, and ask vendors to propose options at different price points. Do not pretend the budget is open-ended when it is not. Vendors will quote to the top of their range and you will reject the response, having wasted their time and yours.

Step 5: Ask Questions That Reveal Capability, Not Just Process

A long list of generic procurement questions (“describe your project management methodology”, “list three references”) produces a generic response that any agency can copy-paste. The questions that actually differentiate vendors are project-specific.

For a portal build, useful questions are: “Walk us through how you would approach authentication for our 120 client users, given we use Google Workspace.” “Have you integrated with Airtable’s API before? What were the limitations you ran into?” “How would you handle the message threads: custom-built, or using an existing library? What are the trade-offs?”

These questions cannot be answered with boilerplate. The responses tell you who has thought about the problem and who is winging it. The best vendors will engage in detail; the weakest will deflect into process-speak. Both are useful signals.

Step 6: Define Evaluation Criteria in Advance and in Writing

Write down how you will score the responses before any responses arrive. The criteria typically include: technical approach, relevant experience, team quality, price, timeline, cultural fit, and risk. Weight them according to what matters most for this project.

A good practice is to publish the weighting in the RFP itself. If you tell vendors that technical approach is 30% and price is 25%, they know what to invest effort in. If you keep the weighting secret, they hedge: long responses on every dimension, deep on none. Published criteria produce sharper responses.

Be honest with yourself about price weighting. If price is 50% of the decision, say so. If it is 20% and what you really care about is the technical approach, say that. Saying “price is one factor among many” while picking the cheapest produces resentment in the market and you stop getting serious bids.

Step 7: Give Vendors Time to Respond Properly

A two-week response window for a six-figure project produces shallow responses. A four-week window produces considered ones. Time matters because the bidding teams have to balance this against their other work. A tight deadline gets handled by whoever is available, not by the senior people you want on the bid.

Build in time for clarification questions, too. Publish a deadline for written questions (a week into the response window), commit to publishing all questions and answers to all bidders (this prevents repeat work and ensures fairness), and then leave at least a week between the answers going out and the response deadline.

If your timeline is two weeks, send the RFP to a smaller shortlist of vendors who already know your business, and acknowledge in the document that the timeline is tight.

Step 8: Plan the Shortlist and Interview Stage

The written response is the filter, not the decision. Plan to shortlist two or three vendors after the written stage and meet them. The meeting is where you find out whether the people who will actually do the work are the ones you want on the project, or whether the polished response was produced by the sales team and the delivery team is a separate, less impressive group.

Ask to meet the senior engineer or project lead, not just the account manager. Walk through one or two of the harder parts of the scope and see how they respond when challenged. The right partner will push back where they disagree. That is a feature, not a bug. A vendor who agrees with everything you say in the interview is the one who will produce a project that goes wrong silently.

Common Mistakes

• Hiding the budget. Produces unusable quotes and wastes the responding vendors’ time. State a band.
• A scope that says “modern” or “scalable” instead of describing what the system does. Adjectives are not requirements. Verbs are.
• Generic procurement questions. “Describe your project management approach” produces boilerplate. Project-specific questions produce signal.
• Too many vendors. Five maximum. Eight is wasteful. Twelve is theatre.
• No “out of scope” section. Without it, every bidder makes different assumptions about what is included, and the quotes are not comparable.
• Bidding open to anyone. Public open bids attract volume, not quality. Curate the invite list.
• Two-week response window. Produces a shallow response. Four weeks is the right balance for a serious project.

What Good Looks Like

A well-written software RFP is twelve to twenty pages, structured in the order vendors read it, with a scope statement specific enough that quotes are genuinely comparable. The budget band is published, the evaluation criteria are weighted in writing, the questions are project-specific, and the response window is four weeks for a six-figure project. The responses that come back vary in approach but not in interpretation of scope: every bidder is solving the same problem. The shortlist meets at the senior level, and the decision is defensible because the criteria were written down before the responses arrived.

Next Steps

The planning guides cover the steps before and after the RFP process. If you have not yet written the underlying scope, start with How to Scope an Internal Software Project. If you are choosing between custom build and configured platform, How to Evaluate Build vs Buy is the right read. If you are also thinking through the longer-term cost picture, How to Budget for Software Maintenance is worth reading alongside this. If you would like to discuss a brief before it goes to market, get in touch or see Custom Software Development for an overview of how we work.