How do you write a good RFP for custom software?

What an RFP Is—and What It Isn't.

An RFP (Request for Proposal) is a request for proposals. You describe your situation, your goals, and your requirements, and invite multiple vendors to submit a proposal: approach, timeline, and price. With custom software, that’s exactly the point. You’re not buying an off-the-shelf product with a fixed price tag, so the RFP is the tool you use to compare proposals from different vendors.

What an RFP is not: a technical design. You describe what you need and why, not how the supplier should build it. That “how” is precisely what you want to use to evaluate the bidders.

RFP vs. RFI vs. RFQ.

These three terms are often used interchangeably, but they serve different purposes. An RFI (Request for Information) explores the market: who are the key players, and what’s possible? An RFP requests a complete proposal that includes an approach, a schedule, and a price. An RFQ (Request for Quotation) asks only for a price for something that has already been fully defined. In a software project, you often use them in this order: first, explore the options; then, request proposals; and only issue an RFQ once the solution is fully defined in detail.

RFP vs. Statement of Requirements.

A Statement of Requirements (SoR) is a structured list of requirements and specifications for the software. The RFP is the broader document: it includes the Scope of Work, plus your context, the selection criteria, and the award process. In short, the Scope of Work is part of your RFP, not a synonym for it.

When to Use an RFP for Custom Software.

An RFP is not an end in itself. It’s useful if you want to seriously compare multiple vendors, if the project is large or complex enough to justify the effort, and if your requirements are reasonably stable. If you have a small or medium-sized project with two or three parties on your shortlist, a good discussion is sometimes faster and more focused than a formal RFP process. An RFP takes you time to write and the suppliers time to respond. Weigh that investment against what you get out of it.

What Should Be Included in a Strong Software RFP.

This is the crux of the matter. An RFP doesn't have to be long, but it does need to be comprehensive in the areas that matter. The following sections should definitely be included.

Business context, rationale, and objectives.

Start by explaining your background. What does your organization do, what is your current situation, and why are you starting this process now? Translate that into specific goals. Not “we want to work more efficiently,” but, for example, “we want to reduce the turnaround time for a quote from three days to one.” Goals that you can measure afterward give suppliers something to base their proposals on.

Scope and Delimitation.

What is included in this project, and just as importantly, what is not? Clearly defining the scope prevents the project from doubling in size along the way. Also identify the points of overlap with existing systems and processes.

Functional and non-functional requirements.

Functional requirements describe what the system must do: which actions, which user roles, which screens. Non-functional requirements concern how well it must do those things: performance, scalability, availability, and usability. Make the latter verifiable. You can’t verify a statement like “The software must be fast.” But you can verify “The API responds within 200 milliseconds for 95 percent of requests.” That’s often exactly where the difference lies between an RFP that yields good proposals and one that doesn’t.

Technical Requirements and Integrations.

Which systems does the software need to interface with? Think of your CRM, ERP, HR system, or accounting software. Describe the critical integrations, what data needs to be exchanged, and whether that should happen in real time or periodically. Integrations are often the most underestimated part of a custom development project, so be specific here.

Security en compliance (AVG, NIS2, ISO 27001).

If the software processes personal data, GDPR requirements must be included in your RFP. If you are subject to NIS2, or if you provide services to an organization that is subject to it, the matter becomes more serious. The NIS2 Directive (formally Directive (EU) 2022/2555, adopted on December 14, 2022) mandates a series of basic measures, including requirements regarding the security of your supply chain, encryption, and incident response.

The deadline for member states to transpose NIS2 into national law was October 17, 2024. The Netherlands did not meet that deadline; the Dutch Cybersecurity Act was enacted later. Therefore, include requirements in your RFP regarding supply chain security, incident reporting, and encryption, and explicitly ask suppliers for certifications such as ISO 27001. Please note: an ISO 27001 certificate is valuable, but it does not equate to NIS 2 compliance. NIS 2 adds, among other things, director liability and a legal obligation to report incidents. If you want to be thorough in this regard, it helps to define your requirements regarding security and privacy early in the process.

Budget, timeline, and milestones.

Many organizations deliberately omit the budget out of fear of being asked for too much. This backfires. Without a budget estimate, you’ll receive proposals that vary widely and are impossible to compare. Provide a range. Also, put your desired timeline and key milestones in writing so that vendors can tailor their approach accordingly.

Selection and award criteria.

What criteria do you use to evaluate the proposals, and how much weight does each criterion carry? Price, approach, experience, technical fit, culture. By establishing the weightings in advance, you ensure a fair comparison and avoid making a decision based on gut feeling.

Maintenance, SLA, further development, and exit.

Software is never “finished.” Ask about post-launch maintenance, the SLA (Service Level Agreement) for response times in the event of incidents, and how ongoing development is organized. And finally, consider this: how do you prevent vendor lock-in, and what would an exit look like if you ever decide to part ways with the vendor? With custom software, ownership of the code is an important point to clarify.

Prioritize your requirements using the MoSCoW method.

Not every requirement is equally important, and you should feel free to make that clear. The MoSCoW method divides your requirements into four categories: Must-have (it won’t work without this), Should-have (important, but not critical), Could-have (a nice bonus), and Won’t-have (deliberately omitted for now). The Must-haves are your deal-breakers.

The method was devised in 1994 by software developer Dai Clegg, who was working at Oracle at the time, and was later incorporated into the DSDM framework for agile projects. A useful rule of thumb from that framework: don’t let your “Must-haves” account for more than sixty percent of the total scope. If you go over that limit, you haven’t really set any priorities, and you lose the flexibility that you need most in custom development.

Common Mistakes in a Software RFP.

Most RFPs fail because of a handful of the same mistakes. Over-specifying tops the list: you describe the solution in such detail that a good vendor can no longer contribute their own ideas. Next come vague, unverifiable requirements, which result in proposals you can’t evaluate. Omitting a budget estimate is the third classic mistake. Also common: copying requirements from another organization’s RFP, which leads you to request functionality you don’t need at all.

The most frustrating contradiction often comes last: wanting to work in an agile way, but at the same time demanding a fixed price for a fixed scope. You can’t have both. Agile means that the scope evolves based on what you learn along the way. A fixed-price quote, on the other hand, means the scope is set in stone. If you ask for both, you’re forcing suppliers to build a buffer into their price—or you’ll end up with proposals that can’t be compared. Choose wisely.

When an RFP Isn't the Best Approach.

Sometimes an RFP is simply the wrong tool. In highly iterative or innovative projects, the requirements aren’t fixed in advance; you don’t yet know exactly what you need, because you discover that as you go along. If you cram that uncertainty into a rigid RFP, you’re forcing everyone to pretend the project is predictable. It isn’t.

In that case, a different approach works better. An RFI to first explore the market. A market consultation. Or a joint kickoff: a short, intensive phase in which you work with a partner to refine the scope, the requirements, and a realistic estimate before a single line of code is written. For many custom development projects, this is a fairer starting point than a formal RFP process, because you refine the requirements together rather than having to guess them in advance.

From RFP to the Right Software Partner.

A good RFP is half the battle. The other half is evaluating the responding vendors: their experience, their approach, their reliability, and whether there’s a good fit. While the RFP focuses on the requirements you set, the selection process focuses on how you evaluate a bidder against those requirements. That’s a separate skill set, with its own key considerations and red flags. You can read about how to approach this in our article on [choosing a software partner]. If you’re unsure whether custom development is the right path to take, that’s exactly the kind of question that belongs at the beginning of your digital transformation.

To summarize briefly.

An RFP for custom software defines your problem, your goals, and your requirements—not a ready-made solution—so that you receive comparable and realistic proposals. At a minimum, include: business context, objectives, scope, functional and non-functional requirements, technical requirements and integrations, security and compliance (GDPR, NIS2, ISO 27001), a budget estimate, timeline, selection criteria, and agreements regarding maintenance, SLAs, and vendor lock-in. Prioritize using MoSCoW and keep your “Must-haves” under sixty percent of the scope. And know when to stop: for highly iterative projects, an RFI, a market consultation, or a joint Sprint 0 is often more effective than a fixed-scope RFP.