Most RFP templates for custom software are useless. They were written for procurement teams to compare apples to apples on commodity work — and custom software isn't commodity work. The questions miss what actually matters. The structure invites lazy answers.
Here's a custom software RFP template that actually elicits the information you need to compare vendors. Use it as-is or adapt to your situation.
Section 1: Project context
Tell the vendor enough to give a useful answer.
- Company snapshot: what you do, size, industry, why this software matters to your business
- Current state: what you use today, what's working, what's not
- Decision drivers: what's the #1 outcome that would make this project a success
- Constraints: timeline, budget range, must-haves
Don't write a 30-page RFP. 2–3 pages here is usually enough.
Section 2: Scope description
Be specific about what's in and what's out. The "out of scope" list is the most important part.
- In scope: features, integrations, user types, data model, expected scale
- Out of scope: features you've considered and decided against (for now), future phases, things you'll handle yourself
- Open questions: things you're genuinely unsure about, where you want the vendor's recommendation
Section 3: Technical environment
What context the vendor needs to scope appropriately:
- Current stack: tech stack today, key vendors, integrations
- Compliance needs: SOC 2, HIPAA, GDPR, etc.
- Hosting preferences: your cloud vs theirs, specific region/availability requirements
- Data sensitivity: PII, financial data, healthcare data
- Performance targets: users, transactions, data volume
Section 4: The 8 questions that actually differentiate vendors
- What's your "out of scope" list for our project? Tests if they've actually read the RFP.
- What 3 projects have you delivered similar to ours? Can we see the live software? Tests track record specifically vs vague portfolio.
- What's your weekly demo cadence and what does week 1, 2, 3 deliver? Tests methodology.
- What does code ownership look like in the contract? Tests if you'll actually own what's built.
- What's your team composition for this project and can we meet the lead engineer? Tests if you're getting senior people.
- What's your fixed-price vs time-and-materials approach? Tests if they'll commit to a price.
- What happens if the project goes 20% over scope? Tests if they understand and price scope creep.
- What's your warranty and exit story? Tests if they're set up for ownership transfer.
Section 5: Pricing structure
Specify the response format so apples-to-apples comparison is possible:
- Fixed total broken down by phase
- Payment schedule tied to milestones
- Out-of-scope rate for additions
- Maintenance options post-launch
If a vendor responds with hourly rates and no fixed total, that's information about how they work.
Section 6: Evaluation criteria
Tell vendors how you'll evaluate so they can lead with what matters:
- Track record (relevant similar projects)
- Methodology (weekly demos, fixed scope, etc.)
- Team (senior, dedicated, named)
- Price (and price structure)
- Ownership terms
- Cultural fit (subjective but matters)
Weight these explicitly. A vendor knows to lead with weeks-by-week deliverables if that's 25% of your evaluation.
What to leave out
Don't include:
- 50 generic "company background" questions
- Detailed legal terms (those come later)
- Penalty clauses for missing arbitrary deadlines (kills proposals from good vendors)
- Demands for unrealistic free work (proof-of-concepts, free designs)
These signal that you don't understand custom software development. Quality vendors will pass on RFPs that contain them.
How to use this template
- Adapt to your situation
- Send to 3–5 vendors (more is overkill)
- Schedule 30-minute follow-up calls with each
- Evaluate using the criteria you specified
- Pick the vendor whose answers to the 8 questions in section 4 are most specific and credible
For our own answers to those 8 questions, see 5 Questions to Ask Any Vendor. Or get a transparent quote via the cost calculator.