A good RFP for software development describes the problem you need solved and the result you expect, then asks vendors to show how they would get there. Most bad RFPs do the opposite: they dictate a solution in 30 pages of requirements and get back 30-page proposals that promise everything. Keep yours short, keep it about outcomes, and ask every vendor for the same few things so you can compare them side by side.
Key Takeaways
- Write the problem and the outcome; leave the solution to the vendors, who may see options you have not.
- Ask for short proposals. A vendor who can explain the approach in five pages understands it.
- Judge on technical approach, team, similar work and price, with price carrying less weight than the other three.
- Require working software on a regular schedule, delivered into a code repository you own.
What Goes in an RFP for Software Development
The clearest public guidance on buying custom software comes from government buyers who learned the hard way. 18F, the federal digital team that wrote the De-risking Guide (the office closed in 2025; the guide is archived), says a statement of objectives requires six elements: purpose, scope or mission, period and place of performance, background, performance objectives, and any operating constraints. Notice what is missing: a list of screens and buttons.
Harvard Kennedy School's RFP guidebook makes the same point in plainer words: "By avoiding specific solutions in the problem statement, you leave space for vendors to draw on their own expertise and offer solutions you may not have considered." Its sample outline is the backbone of the template below. I adapted it for a private company buying one app.
RFP: [Project name]
Issued by: [Company], [contact name and email]
Key dates: questions due [date] / proposals due [date] / interviews [dates] / decision [date]
1. THE OPPORTUNITY
- What the business does today, in one paragraph
- The problem: who struggles, how often, what it costs you now
- The outcome you want in 6 months (a number if you can: hours saved, orders per week)
2. SCOPE
- Who will use the software (staff, customers, both)
- What must exist at launch, in plain words
- What can wait for a second phase
- Systems it must connect to (accounting, payments, email)
- Constraints: budget range, deadline, data rules (health or payment data?)
3. HOW WE WILL WORK
- Working software shown every 2 weeks
- All code in a repository we own from day one
- One named lead on your side for the whole project
4. WHAT TO SEND US (5 pages max)
- Your approach to this problem and what you would build first
- Who would work on it, with their roles
- Two similar projects, with a client we can call
- Price: fixed price per phase, or estimate plus rate, with assumptions listed
5. HOW WE WILL CHOOSE
- Approach, team and similar work matter more than price
- Short interview with the people who would do the work
- No points spreadsheet: we decide as a group after interviews
6. TERMS
- Attach your draft contract or list must-haves (IP, warranty, payment by milestone)
The Four Choices That Decide Proposal Quality
Length limits. 18F told agencies to keep proposals "under 10 pages" and recommended "a hard limit of five pages." Short limits filter out vendors who pad and force the good ones to commit to an approach.
What you judge on. The same guide uses only four factors: "technical approach, staffing approach, similar experience, and price," and says the first three "will be given more weight than price." Cheap and wrong is the most expensive outcome in custom software. See what a good software quote looks like for how to read the price section.
Interviews with the actual team. The guide "strongly recommends" interviews to validate written proposals, and suggests naming only "two or three positions at most: a project lead, a technical lead and, optionally, a design lead." Meet those people. A proposal written by a sales team tells you little about who builds.
Working software as the standard. 18F's rule was that at the end of each sprint, all code goes to a government-owned repository and must be "complete, tested, accessible, deployed, documented, and secure." Swap "government-owned" for "your company's" and you have the best single clause in any software RFP.
A Concrete Version
A landscaping company with 14 crews schedules everything on a whiteboard and a shared spreadsheet. The owner wants crew scheduling plus a client page where customers can approve quotes.
She writes a four-page RFP using the outline above. The outcome line says: "Cut the 6 hours a week the office spends rebuilding the schedule to under 1." She sends it to five vendors with a two-week deadline and a five-page cap.
Four respond. One sends 40 pages anyway, and she drops it. She interviews the other three, in a week. Total time from first draft to decision: two weeks writing, two weeks for responses, one week of interviews, so five weeks.
She does not award the whole thing. She buys phase one, scheduling only, at a fixed $24,000, with the client page as a separate phase two quote. 18F's advice for large public projects was to "carve a large project into several small ones," and it works just as well at $24,000.
The Honest Counterpoint
An RFP is overkill for a small build. If the whole project is likely to cost less than a few months of an office salary, a formal RFP takes more of your time than the project deserves and scares off small, good shops that do not answer RFPs at all. Write a one-page brief instead, send it to three vendors, and talk to each for 30 minutes.
RFPs also reward vendors who are good at writing proposals. That skill overlaps with building software less than you would hope, which is why the interview and the reference call matter more than the document.
Frequently Asked Questions
How long should an RFP for software development be?
For a small or mid-size business, three to six pages is enough. Cap the responses too: five pages is a good limit.
Should I include my budget in the RFP?
Include a range. Without one, vendors guess, and you get proposals that are impossible to compare: one sized for $20,000 and another for $200,000.
What should I ask vendors to send?
Their approach to your specific problem, the named people who would do the work, two similar projects with a reference you can call, and a price with its assumptions written out.
The Bottom Line
Describe the problem, cap the length, meet the real team and demand working software in a repository you own. That one discipline does more than any scoring matrix. If you are hiring engineers rather than buying a project, use our staff augmentation RFP template instead, and see how to vet a development agency for the reference calls.
Before you write a word, get Sol's free Honest Read. It turns your idea into a plain-English report with real cost ranges, which makes a strong opening section for your RFP (here is what it includes). Or send the same brief to our fixed-price software factory.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers, with a vetted shortlist in 72 hours. See available engineers.
