The best RFP we received last year was four pages long. It bought a better product for less money than the 38-page document that arrived the same month, because every vendor who read it could price the actual problem instead of pricing their own uncertainty. When a vendor cannot tell what you want, they add a risk margin. You pay for that margin whether or not the risk exists.
This is the RFP guide from the other side of the table. We are an agency: a few hundred requests for proposal have crossed our inbox, most of them bad in the same five ways. This post covers what a software RFP must contain, what to cut, how AI-assisted development changed the questions worth asking, and the red flags to look for in the responses you get back. It does not cover public-sector procurement, which has its own compliance rules. There is a copy-paste template structure in the middle you can use today.
Why most software RFPs get bad answers
An RFP is a pricing instrument. Vendors read it to answer one question: "Can I estimate this work with confidence?" Every ambiguity forces them to choose between padding the quote or lowballing it and fighting you over scope later. Neither outcome is the vendor being evil. Both are the document's fault.
The stakes are not small. McKinsey and Oxford studied 5,400 large IT projects and found they run 45% over budget on average while delivering 56% less value than predicted (McKinsey). A large share of that gap is set before a single line of code is written, in the document that defined the work.
The five failures we see most often:
- No problem statement. The RFP describes a feature list, not the business problem. Vendors cannot challenge a bad solution they were never shown the reason for.
- No budget signal. "Please quote" with no band produces quotes from $20k to $400k for the same document. That spread is not vendor dishonesty; it is vendors guessing which product tier you meant.
- Prescribed tech stack with no justification. "Must be built in Java with Oracle" filters out the vendors who would have told you a $40k solution exists.
- No evaluation criteria. Vendors who do not know how they will be scored write generic brochures instead of specific answers.
- 40 pages of boilerplate around 2 pages of substance. Good vendors triage inbound RFPs. A document that buries the requirements in legal preamble gets skimmed, and skimmed documents get padded quotes.
The software RFP template: 9 sections
This is the structure we wish every buyer sent. Copy it, fill it in, and keep the whole document under 10 pages. Shorter is genuinely better: it signals that you know what you want, and it raises the quality of every response.
| # | Section | What to write | Length |
|---|---|---|---|
| 1 | Problem statement | The business problem in plain language: who suffers, what it costs you today, what changes if it is solved. No feature lists here. | Half a page |
| 2 | Success metrics | 2 to 4 measurable outcomes. "Reduce manual invoice processing from 3 days to 4 hours." "Support 5,000 concurrent users." Numbers, not adjectives. | Quarter page |
| 3 | Scope: must-have vs nice-to-have | Two lists, clearly separated. This single split lets vendors propose a phased build and gives you clean price comparisons. | 1 to 2 pages |
| 4 | Users and workflows | Each user role and the 3 to 5 workflows that matter most, described as steps, not screens. | 1 page |
| 5 | Data and integrations | Every system the software must talk to, with the direction of data flow. Name the ERP, the payment provider, the auth system. Say which have APIs and which do not. | Half a page |
| 6 | Constraints | Hard requirements only: compliance regimes (GDPR, SOC 2, HIPAA), data residency, existing contracts, hosting mandates, hard deadlines with the reason for the deadline. | Half a page |
| 7 | Budget band | A range, stated plainly: "$60k–$120k for phase one." See below for why this helps you, not the vendor. | 2 lines |
| 8 | Evaluation criteria and weights | How responses will be scored, with percentages. Example: relevant experience 25%, proposed approach 25%, team 20%, price 20%, timeline 10%. | Quarter page |
| 9 | Process and logistics | Response deadline (give 2 to 3 weeks), Q&A window, decision date, response format, and a named contact who answers questions. | Quarter page |
Why you should state the budget band
Buyers hide the budget because they fear every quote will land exactly on it. In practice the opposite failure is more expensive: without a band, vendors design for the wrong tier. The same problem statement supports a $30k build and a $300k build, and both are honest proposals. A band tells vendors which product to design. If you fear anchoring, publish a range with 2x spread and score proposals on what they deliver inside it. We tell clients: the band does not set the price, it sets the conversation.
What to leave out of your RFP
- The tech stack, unless you have a real constraint. "Our team maintains it after handover and knows Python" is a real constraint; write it down. "We read that Next.js is popular" is not. Prescribing the stack converts your best applicants from advisors into order-takers, and you are paying precisely for their advice. If you want to see how vendors think, ask them to propose a stack and defend it.
- Solution design. Describe the disease, not the prescription. An RFP that specifies database schemas and screen layouts has already done the vendor's job, badly.
- Boilerplate legal terms. Reference your standard terms as an appendix or a link. Contract negotiation happens after selection; our software development contract checklist covers the 14 clauses that actually decide disputes.
- 20 vendor-questionnaire pages. Company history, org charts, insurance certificates: ask the shortlist, not all twelve bidders. Every hour of busywork you demand up front is quietly billed back into the quote.
- Fake deadlines. "Responses due in 5 days" filters for vendors with empty pipelines. Well-run agencies are booked 4 to 8 weeks out and will decline rushed RFPs. Two to three weeks with a mid-point Q&A session gets you the strongest field.
How AI-assisted development changed what to ask vendors
Nearly every serious development team now builds with AI. Google's 2025 DORA research found roughly 90% of developers use AI tools in their daily workflow (DORA). That changes the questions an RFP should ask, because the gap between teams is no longer whether they use AI, it is whether they have the engineering discipline to control it.
Add these four questions to section 9 of your RFP:
- "Describe how AI tools fit into your development workflow, and how that affects our price and timeline." AI compresses typing time, not thinking time. A vendor quoting 40% below the band "because we use AI" has misunderstood where the cost of software lives: requirements, integration, and testing.
- "How do you specify work before generating code?" Strong teams write specs and acceptance criteria first, then use AI against them. Weak teams prompt their way to a demo and reverse-engineer the spec later. The first is faster and auditable; the second produces the codebases we get hired to rescue.
- "How is AI-generated code reviewed and tested before it ships?" You want to hear named practices: human review on every pull request, test coverage thresholds, security scanning. "Our engineers check it" is not an answer.
- "If the project includes AI features, how will you evaluate them?" Any vendor proposing an LLM feature should talk about evals: test datasets, accuracy thresholds, failure handling. Gartner predicts over 40% of agentic AI projects will be canceled by the end of 2027, largely for unclear value and inadequate controls (Gartner). Evals are how you avoid being in that 40%.
Red flags in vendor responses
You will learn more from how vendors respond than from what they promise. These are the signals we would act on if we were the buyer:
- No questions asked. A vendor who reads your RFP and asks nothing either did not read it or plans to relitigate scope after signing. The best proposals we have seen open by challenging one of the buyer's assumptions.
- A quote far below the band with no scope reduction. They are buying the deal and will earn it back in change orders. Ask them to walk you through the estimate line by line.
- Fixed price on vague scope, accepted without protest. A vendor who fixed-prices ambiguity has priced in a fight. Serious vendors will push for a discovery phase or a phased contract, and that push is a good sign.
- Team bait-and-switch signals. The proposal showcases senior engineers but will not name who works on your project. Ask for named key personnel in the contract.
- Boilerplate response to your specific problem. If you could swap your company name for another and the proposal still reads fine, they wrote it before they met you.
- No pushback on your nice-to-haves. Everything is "yes, included." Real builds involve trade-offs; a vendor who surfaces none is deferring every hard conversation to the invoice.
Scoring responses against the weights you published keeps this honest. For the fuller diligence pass, reference checks, portfolio verification, and engagement models, use our checklist for hiring a web development company; if you are commissioning a product rather than a project, our guide to comparing SaaS development vendors covers the differences that matter there.
The process, start to finish
The timeline we recommend to clients running a competitive RFP:
- Week 0: Write the RFP with the 9-section template. Send to 4 to 6 pre-screened vendors, not 20. Response quality drops when vendors sense a lottery.
- Week 1: Hold one shared Q&A call or written round. Share all answers with all bidders; private answers create unfair spreads you cannot compare.
- Weeks 2 to 3: Responses due. Score independently against the published weights before discussing as a group.
- Week 4: Shortlist 2 or 3 vendors for working sessions. Give each the same small real problem and watch how they think. This hour tells you more than the whole written proposal.
- Week 5: Select, then negotiate the contract. Selection and negotiation are separate steps; collapsing them weakens your negotiating position.
Frequently asked questions
How long should a software RFP be?
Five to ten pages. Under five usually lacks the data and integration detail vendors need to price accurately; over fifteen buries the requirements and lowers response quality. The strongest RFPs we receive spend most of their length on the problem, workflows, and integrations, and almost none on boilerplate.
Should I include a budget in my RFP?
Yes, as a band with roughly 2x spread, such as $60k–$120k. Without it, vendors design for different product tiers and their quotes cannot be compared. The band does not become the price; it defines which class of solution you are asking vendors to design.
How many vendors should receive the RFP?
Four to six pre-screened vendors. Fewer than four gives you no market signal; more than eight signals a lottery and good vendors respond with less effort or decline. Pre-screen on portfolio and industry fit before sending anything.
What is the difference between an RFP, RFI, and RFQ?
An RFI (request for information) surveys the market when you do not yet know what you need. An RFQ (request for quotation) prices a precisely specified purchase. An RFP sits between them: you define the problem, constraints, and success metrics, and vendors propose the solution and the price. Custom software almost always belongs in RFP territory, because the solution design is part of what you are buying.
Should the RFP specify the technology stack?
Only when a real constraint exists: your in-house team will maintain the code, a compliance regime dictates hosting, or an existing platform must be extended. Otherwise ask vendors to propose a stack and justify it. How they defend that choice is one of the best evaluation signals available, and prescribing it up front deletes the signal.
Key takeaways
- An RFP is a pricing instrument: every ambiguity becomes either a padded quote or a future change order.
- Nine sections, under ten pages: problem, metrics, scope split, workflows, data and integrations, constraints, budget band, scoring weights, process.
- State a budget band with 2x spread. Hiding it produces quotes you cannot compare.
- Leave out the tech stack, solution design, and questionnaire busywork. You are buying judgment; let vendors show it.
- Ask every vendor how they spec, review, and evaluate AI-assisted work. The answers separate engineering teams from prompt-and-pray shops.
- The loudest red flag in a response is silence: no questions, no pushback, no trade-offs.
Send us your RFP, even a rough one
If you have a draft RFP, or just the problem statement that should become one, send it over and we will tell you what a vendor reading it would quote high for, what is missing, and whether the project is worth running at all. If the honest answer is that an off-the-shelf tool solves it for 5% of the cost, that is what we will say. And if you want our custom software development team to be one of the bidders, we respond to well-written four-page RFPs with unreasonable enthusiasm.