How to Write an RFP for Custom Software

Who This Guide Is For

Procurement managers, IT leads, and business owners who need to formally solicit proposals from multiple software development agencies. This guide is for situations where a structured evaluation process is required, whether that is internal governance, competitive bidding, or a complex project where multiple perspectives are valuable.

Before You Start

• An RFP is not always necessary. For smaller projects, or when you already have a trusted partner, a brief and a conversation are more efficient. If your project is closer to that, our guide on how to write a brief for a software agency is the better starting point. RFPs add overhead for both sides. Use them when the project scale or organisational requirements justify the process.
• Define your evaluation criteria before writing the RFP. Knowing how you will score responses shapes what you ask for.
• Allocate time for questions. Good agencies will have questions. Build a Q&A period into your timeline.

Step 1: Write the Introduction

Cover the basics: who you are, what your business does, why you are issuing the RFP, and what you are looking for at a high level. This section should be one page maximum. Agencies read dozens of RFPs, so respect their time by being concise.

Include your company name, industry, approximate size, the project’s strategic context, and the RFP timeline (submission deadline, evaluation period, expected decision date).

Step 2: Define the Project Scope

Describe the project in terms of outcomes and problems, not features. Provide enough detail for agencies to understand the scale and complexity, but avoid prescribing the technical solution.

Include the business problem being solved, the current state (existing tools, workflows, pain points), the desired future state, key integrations required, expected user types and volumes, and any compliance or regulatory requirements.

Step 3: Specify Response Requirements

Tell agencies exactly what you want in their response. This makes proposals easier to compare. Typical sections to request:

• Understanding of the problem. How does the agency interpret your needs?
• Proposed approach: the high-level technical approach, methodology, and delivery timeline.
• Team composition: who will work on the project and what their relevant skills are.
• Relevant experience: similar projects completed, with references if possible.
• Pricing, whether fixed price, time-and-materials estimate, or phased pricing. Specify which format you want.
• Post-launch support: how the agency will support the system after delivery.

Step 4: Set Evaluation Criteria

Be transparent about how you will evaluate proposals. Common criteria with weightings:

• Understanding of requirements (25%). Does the agency demonstrate that they understand the problem?
• Proposed approach (25%). Is the technical approach sound and well-explained?
• Relevant experience (20%). Has the agency delivered similar projects successfully?
• Pricing (15%). Is the pricing reasonable and clearly structured?
• Cultural fit and communication (15%). Did the agency ask good questions? Are they clear communicators?

Sharing these criteria upfront helps agencies focus their responses on what matters to you.

Step 5: Define the Process

Lay out the complete timeline: RFP issue date, Q&A deadline, submission deadline, shortlist notification, presentation or interview dates, and decision date. Specify how questions should be submitted and whether answers will be shared with all respondents.

Be clear about what happens after selection, including contract negotiation, kickoff timeline, and any procurement or legal requirements.

Common Mistakes

• Making the RFP too long. A 40-page RFP with boilerplate legal sections discourages strong agencies from responding. Keep it focused on what the agency needs to know to propose effectively.
• Prescribing the technology. Unless you have a genuine constraint (for example, the system must integrate with an existing .NET stack), let agencies recommend the technology. They know what works.
• Weighting price too heavily. The cheapest proposal is rarely the best. Evaluate on overall value, which means understanding, approach, experience, and price considered together.
• Not allowing enough time for responses. Two weeks is the minimum for a meaningful proposal. Three to four weeks is better for complex projects.
• Skipping the Q&A period. Questions from agencies often reveal ambiguities in the RFP that you can clarify for everyone, improving all responses.

What Good Looks Like

A strong RFP is concise (under 15 pages including appendices), outcome-focused, transparent about evaluation criteria, and respectful of the agency’s time. It gives enough information to propose meaningfully without prescribing the solution. The best RFPs generate thoughtful, differentiated responses rather than boilerplate proposals.

Next Steps

Once you have received and evaluated proposals, the next step is typically a presentation or interview with your shortlisted agencies. If you need help evaluating proposals or assessing technical approaches, our technical consulting service can provide an independent perspective. For the wider decision that follows, our guide on how to choose a software development partner walks through the same evaluation in more depth, and you can read what an actual engagement involves on our custom software development page.