How to write an RFP for software that attracts the right vendors

A request for proposal (RFP) for software is a document that hands vendors enough specifics to quote accurately and to self-disqualify when they are not a fit. Done well, it cuts your shortlist from twenty noisy responses to four serious ones. Done badly, it wastes six weeks and produces proposals you cannot compare.

The hard part is not formatting. It is making the constraints explicit. 73% of RFP disqualifications trace back to scope misalignment or incomplete scope responses. That is not a vendor problem. That is the brief leaving room for interpretation.

Here is the 8-section structure we use when a client asks how to write an RFP that filters early, scores fairly, and ends in a contract instead of another round of clarification calls.

What the RFP is really for

An RFP serves three audiences at once: you, your stakeholders, and the vendors. For you it forces alignment between product, engineering, finance, and legal before any vendor reads it. For stakeholders it produces an apples-to-apples comparison. For vendors it tells them whether to bid full attention, decline politely, or push back on assumptions.

If you can write a single page that does those three things, you do not need an RFP at all. Send the page to four shops and book calls. The RFP exists because most software projects involve compliance, integrations, multi-year support, or budgets that need procurement sign-off, and the document is the artefact that survives team turnover during the buying cycle.

The 8 sections that do the filtering

1. The problem, not the solution

Open with the business problem in plain language: who is hurt, how often, what it costs you today. Resist the urge to specify the solution. Vendors who can shape a better approach will only show that thinking if you leave them room. Vendors who copy your prescribed solution into the proposal are flagging themselves as the wrong fit.

One concrete sentence per problem. "Our finance team reconciles 40,000 transactions per month across three payment processors by hand, which takes 12 working days and produces a 3% error rate" is useful. "We need to streamline reconciliation" is not.

2. Scope in and scope out

List the in-scope deliverables as nouns. Then list the explicitly out-of-scope items: legacy data migration beyond a defined cutoff, mobile native apps, custom reporting, third-party integrations not named here. The out-of-scope list does more filtering than the in-scope list, because it kills the "yes to everything" proposals that look generous until you read the change order clause.

Scope creep is the top project challenge for 59% of vendors, according to DesignRush industry data, and the gap usually opens in week three. Closing it in the RFP costs you ten extra lines and saves you a quarter of margin.

3. Constraints: budget, timeline, and decision date

Name a budget range, not a ceiling. "USD 180k to 240k for phase one" tells a serious vendor whether to bid; "competitive" tells them you have not done the work. Hidden budgets correlate with cost and schedule overruns: when budget and timeline are concealed, projects run late and over budget at near-coin-flip rates.

Name a decision date. Vendors quote differently for a 4-week selection than for a 10-week one because the latter consumes business development hours. Name a target start date. Name the project sponsor and who signs.

4. Non-functional requirements

This is where most RFPs leak. Specify the things that turn the project from "build it" into "build it for production":

• Concurrent users, peak and average
• P95 response time per endpoint class
• Uptime target and the maintenance windows that count against it
• Data residency, retention, and deletion windows
• Audit log and observability expectations
• Recovery point and recovery time objectives

A vendor who quotes a number that contradicts these constraints (for instance shared cloud regions when you required EU residency) self-disqualifies in the first review pass.

5. Integrations and existing systems

Name every system the new software must touch: identity provider, billing, CRM, data warehouse, analytics, the legacy database that nobody wants to touch but everyone depends on. Include version numbers and authentication models. For each integration, state whether the vendor builds the connector, your team builds it, or both meet at an API contract.

When this section is vague, two vendors building the same thing will price it three times apart. When it is specific, you get to compare two numbers that mean the same thing.

6. Security and compliance

The non-negotiables in 2026: SOC 2 Type II within the last 12 months, GDPR data processing terms, encryption at rest and in transit, an incident response plan, and a software bill of materials for every dependency the vendor introduces. Industry-specific add-ons stack on top: HIPAA for healthcare, PCI-DSS for card data, ISO 27001 for enterprise procurement.

List the certifications as line items, not in a paragraph. Vendors who cannot tick them all do not waste your time arguing the merits.

7. Team and delivery model

Ask for the names of the people who will work on the project: the engineering lead, the designer, the PM. Ask for the percentage of their time committed. Ask for the bench in case someone leaves. This single requirement filters out shops that plan to sign with senior staff and deliver with juniors.

Ask the delivery model: fixed-price, time and materials, dedicated team, or staff augmentation. Ask the cadence: ceremonies, demos, and the artefact you receive at the end of each sprint or milestone.

8. Evaluation criteria with weights

Publish the scoring rubric inside the RFP. A typical weighting for a SaaS build: functional fit 30 to 35%, security and compliance 20 to 25%, price 20 to 25%, vendor viability and references 15%, cultural fit and delivery process 10%. Adjust by project type, not by mood.

The published rubric does two jobs. It forces vendors to invest where it counts (a vendor who knows price is 25% will not try to win on price alone). And it disciplines your evaluation team into scoring the same thing the same way. Standardised evaluation criteria correlate with 23 to 31% better pricing and 28 to 35% shorter procurement cycles.

What to leave out

Three categories of content waste pages and lose vendor attention.

Marketing about your company. Two sentences of context are enough. Vendors will research you in 30 seconds if they are interested.

Solution dictation. Anything that says "the system must use React" or "must run on AWS" without a business reason. State the constraint behind the constraint (existing team skills, existing infrastructure, compliance need) and let the vendor agree or push back.

500 yes/no compliance questions. Long checklists feel thorough but they reward the vendors with the largest proposal teams, not the best fit. Pick 20 questions that matter. Score them.

How long the document should be

The sweet spot for a mid-sized SaaS build is 8 to 15 pages of body, with appendices for wireframes, data model sketches, and detailed compliance schedules. Below 6 pages you are sending vibes. Above 30 pages you are filtering for vendors who specialise in writing proposals, not in shipping software.

Distribution and shortlist

Send the RFP to a shortlist of 4 to 6 vendors. Public bids attract 20+ responses and consume two weeks of evaluation before the first call. A pre-shortlist (paid discovery call with 8 vendors, RFP to 4) almost always produces a better field than an open bid.

Give a 3 to 4 week response window. Anything shorter signals you do not respect the vendor's process. Anything longer lets the project slide on your side.

After proposals arrive

Score independently before you compare notes. Group scoring at the table converges on the loudest voice, not the best fit. Each evaluator scores against the published rubric, then the group reconciles outliers with a written justification.

Run reference calls before the demo, not after. References at the end of the process are a formality; references early are a filter. Ask for one reference that ended badly and what they learned. Vendors who can answer that question are the ones to take seriously.

For more on how to shortlist vendors once proposals arrive, see our pieces on studio vs freelancer vs agency in 2026 and how to compare SaaS design agencies.

Sources

• What is RFP Project Scope (Arphie)
• How To Write a Software Development RFP in 2026 (DesignRush)
• SaaS RFP Template (CloudNuro)
• RFP Evaluation Criteria (Inventive.ai)
• 10 Mistakes To Avoid In Software RFPs (Mobisoft)
• Software Bill of Materials (CISA)