blog single

Writing an RFP for custom software

Team preparing a software requirements document

Published on:

April 10, 2025

TAG:

PROCESS

BY:

Edgeless Team

Read Time:

5 MIN READ

post detail

An RFP for custom software often produces responses that are impossible to compare. One vendor quotes a fixed price for a vague scope, another quotes a range, and a third sends a capabilities deck. The problem is usually the document. A good RFP describes the problem, the constraints and the decisions the vendor must make, not a feature list copied from a similar project.

An RFP is a decision document

The purpose of the document is to help you choose a partner and a shape for the work. That means it needs to state the outcome, the constraints and the criteria you will use. It does not need to specify every screen. Vendors who are good at discovery will propose a better solution than one written into the requirements.

Write the outcome in business terms. What should change for the team or the customer. What is expensive today. What has been tried. A vendor who understands the problem can suggest a smaller build, and a smaller build is often the best response you will receive.

What to include

The problem and the people affected, with a few real examples.
The systems the work must connect to, including their age and access.
Hard constraints: budget range, deadline, compliance rules, hosting.
What already exists and must be kept, including data and integrations.
The decisions you have made and the ones still open.
How you will evaluate proposals and who will decide.
The expected shape of the engagement, such as discovery first.

Be honest about the budget range. A vendor who knows the range can propose a scope that fits it. Without a range, every response is a guess, and the cheapest guess is often the one that will need the most change orders. The range does not have to be precise. A band is enough to shape the response.

What to leave out

Leave out a long list of screens and fields. It anchors every vendor to the same design and prevents them from suggesting a simpler flow. Describe the tasks people need to complete and let the vendor propose the interface. Include a screen list only where a regulatory or contractual requirement fixes it.

Leave out the requirement that the vendor must use a specific technology unless there is a real operational reason. A stack chosen by the last contractor can exclude the team best suited to the problem. State the constraints that matter, such as existing systems, hosting or team skills, and let the rest be part of the proposal.

How to compare responses

Score each response on the same criteria, with weights agreed before the responses arrive. Useful criteria are understanding of the problem, approach, relevant experience, team, plan and price. A response that restates the requirements without challenging anything usually scores low on understanding, even if the price is attractive.

Ask each vendor to describe the first four weeks. That answer shows whether they plan to understand the problem or start building from the document. It also exposes whether the people in the pitch will be the people doing the work.

Team comparing vendor proposals side by side — Use the same scorecard for every response. The vendor with the longest document is rarely the one with the clearest plan.

Price is a structure

Ask how the price is built. A fixed price for a defined scope, a time and materials estimate with a cap, or a monthly team. Each structure shifts risk. A fixed price protects the budget but usually includes a contingency and a strict change process. A capped estimate shares risk but needs active management.

Ask what happens when the scope changes. The answer should describe how changes are estimated, approved and recorded. A vendor who cannot explain that process will manage change through surprise invoices.

Run a real questions round

Send the same questions to every shortlisted vendor in writing, and share the answers with all of them. That keeps the process fair and surfaces assumptions that were invisible in the first response. Questions about data access, testing and handover usually produce the most useful answers.

Ask how they will know the project is working. A vendor who describes a measurement plan before the build has thought about outcomes. A vendor who describes only deliverables has thought about output, which is a different thing and often the reason projects finish without changing anything.

Ask what they would cut if the budget dropped by a third. The answer reveals priorities and whether the team can distinguish a core feature from a nice one. It also gives you a fallback if the business situation changes after the contract is signed.

Evaluate the team behind the logo

Ask who will do the work and meet those people. Large firms often present senior staff and deliver with a different team. That is not automatically bad, but you should know the names, the roles and how much of the week they will spend on the project.

Look for a team that asks questions about the problem before proposing a solution. A response that fits the brief perfectly on the first read is often a response that has not engaged with the constraints. Curiosity in the sales process usually predicts curiosity in delivery.

Common mistakes

The most common mistake is writing the solution into the requirements. It removes the vendor's ability to propose something better and makes every response a price for the same guess. Describe the problem and the outcome, then judge the proposed approach.

The second is choosing on price alone. The lowest quote is often the one with the thinnest scope, and the difference returns as change orders or as missing work discovered after launch. Compare the scope behind each price, and compare the plan for the first month.

The third is skipping the reference call. A fifteen minute conversation with a past client reveals how a team behaves when a deadline slips or a requirement changes. Those moments are the ones that determine whether the project is a good experience.

The process after submission

Shortlist two or three and pay for a small piece of work. A one week discovery, a technical spike or a design exercise reveals more than any presentation. It also gives you a sense of how the team communicates when the work is real.

Check references from clients with a similar problem, not just a similar industry. Ask what went wrong and how the vendor handled it. Every project has a difficult week, and the answer tells you more than the list of successes.

Keep the timeline realistic. A two week response window with a questions round and a shortlist meeting is enough for most projects. A rushed process produces rushed proposals, and the vendor who had time to think is often the one with the better plan.

A good RFP describes the problem clearly enough that a smart vendor can propose something smaller than you imagined.
Edgeless Team

Tell every respondent what happened and why. A short note with the decision and the reasoning keeps the process fair and keeps the good vendors interested in the next round.

We help teams shape software briefs, run discovery and compare delivery options before committing to a build.

Explore software development

The best RFP is short, specific about the problem and open about the constraints. It gives vendors enough to propose a real plan and gives you enough to compare the plans on evidence rather than presentation.

Procurement

Software

Planning

Writing an RFP for custom software

Let's Talk About Your Project