RFP for software development: free template and how to score replies

How to write and send a software development RFP

1. Write your requirements firstUse a business requirements document or SRS as the source. The RFP summarizes them; it does not replace them.
2. Fill in the seven sections belowKeep it short enough that a vendor can read it in one sitting. Attach longer documents instead of pasting them in.
3. Pick a shortlistSend it to a handful of vendors you have actually checked. Sending it to dozens means more reading and weaker replies.
4. Allow a question roundSet a date for written questions and share every answer with every vendor, so everyone bids on the same facts.
5. Give a fair deadlineGood proposals take time to prepare. A rushed deadline rewards copy-paste replies.

1. About your company

• Who you are, what you sell and who your customers are.
• Team size and who will be the main contact.
• Example: “We are a 25-person property management company in Tampa managing about 900 rental units. Our operations director will own this project.”

2. Project summary and goals

• The problem in two or three sentences.
• What a successful result looks like, ideally with measures.
• Example: “Tenants report maintenance issues by phone and email, and requests get lost. We want a tenant portal and staff app where every request is logged, assigned and tracked to completion.”

3. Scope of work

This section becomes the first draft of the statement of work (SOW) you sign with the winning vendor, so be as clear as you can.

• Main features, grouped by user: tenants, staff, owners.
• Platforms: web, mobile, or both.
• Integrations with existing systems, and data to import.
• Services you expect beyond building: design, hosting, training, support.
• What is out of scope.
• Example: “Tenants submit requests with photos. Staff assign them to technicians. Owners see a monthly report. Must sync with our accounting system. Out of scope: rent collection.”

4. Technical requirements and constraints

• Systems that must stay and how the new software connects to them.
• Security, privacy or compliance rules.
• Any preference on technology, hosting or ownership of the code, and why.
• Example: “We must own the source code and the hosting account. Tenant data must stay in the US.”

5. Timeline and budget

Share a budget range. Vendors who know the range can propose what fits; without it you get proposals that are impossible to compare.

• Target launch date and any fixed deadlines.
• Budget range, and whether you prefer a fixed price, time and materials, or a monthly plan.
• Example: “Launch before our annual lease renewals in August. Budget range $40,000 to $70,000 for the first version, or an equivalent monthly arrangement.”

6. What to include in your response

Ask every vendor for the same things, in the same order, so the replies line up.

• Their understanding of the problem, in their own words.
• Proposed approach and process, including how they handle changes.
• The team who will actually work on it, and who your day-to-day contact is.
• Timeline with milestones.
• Pricing, broken down by phase or by month, plus ongoing costs after launch.
• Two or three similar projects and references you can call.
• Questions, risks or assumptions they see.

7. Evaluation and timeline for the RFP itself

• Key dates: questions due, answers shared, proposals due, decision.
• How responses will be scored (share the categories below).
• Whether shortlisted vendors will present or meet.
• Example: “Questions by May 2. Answers shared May 6. Proposals by May 20. Shortlist calls the week of May 27. Decision by June 7.”

How to evaluate RFP responses

1. Set weights before you open anythingFor example: understanding of the problem 25, approach 20, team 20, price and value 20, references 15. Deciding afterward lets the cheapest or slickest proposal win by default.
2. Score each reply separatelyHave two or three people score on their own, then compare. Big disagreements show where to ask more questions.
3. Read for understanding, not polishThe best replies restate your problem accurately and raise risks you had not considered. Generic replies describe the vendor instead of your project.
4. Compare total cost, not the headlineAdd hosting, support, change requests and the cost of the first year after launch. A low build price with expensive changes can cost more.
5. Call references and meet the teamAsk references what went wrong and how it was handled. Meet the people who will do the work, not only the sales lead.
6. Turn the winner into a statement of workConvert the chosen proposal and your scope into a signed SOW and agreement before any work begins.

Common RFP mistakes

• No budget range, so proposals land anywhere from a few thousand dollars to several hundred thousand.
• Prescribing the solution in detail instead of describing the problem.
• Asking for a fixed price on a scope that is still vague.
• Choosing on price alone without reading how changes and support are handled.
• Never telling the vendors who lost. A short, polite note keeps the relationship for next time.