Skip to main content

Planning

How to Write an RFP for Custom Software

A structured guide to writing a Request for Proposal for custom software development -- what to include, what to avoid, and how to evaluate responses.

Category Planning
Read Time 4 min read
Updated April 2026
Steps 5 steps

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 — internal governance, competitive bidding, or complex projects 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. 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 — respect their time by being concise.

Include: 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. High-level technical approach, methodology, and delivery timeline.
  • Team composition. Who will work on the project and what are their relevant skills?
  • Relevant experience. Similar projects completed, with references if possible.
  • Pricing. Fixed price, time-and-materials estimate, or phased pricing — specify which format you want.
  • Post-launch support. How will the agency 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/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 — 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 (e.g., 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 — understanding, approach, experience, and price 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, Technical Consulting can provide an independent perspective.

Need Hands-On Help?

Our guides give you the thinking. If you want someone to do the building, we should talk.

Start a Project Browse Case Studies