Software Development RFP: What to Ask For Instead of a Feature List

A software development RFP asks vendors to price work that does not exist yet. The bigger the project, the worse that goes. The federal De-risking Government Technology guide reports the pattern in numbers.

Among government software projects costing more than $6 million, 13 percent succeed. Among those under $1 million, 57 percent do. Larger budgets buy longer requirement lists, and longer lists have not saved these projects.

So the useful question for a buyer is not how to specify more. It is what to ask for instead.

Key Takeaways

 

• A three-hundred-line feature list buys you padded bids, lowball bids, and change orders. State outcomes with acceptance criteria instead.
• Check that a vendor can deploy code to your environment before you publish, not after award.
• Split the work into pieces that each stand alone, and keep your right to stop after any one.
• The firm that builds your software should not be the only one able to host, deploy, or read it.
• Name the pricing model, the code and data rights, and the exit terms in the RFP. All three get harder to negotiate once a vendor has won.

The Requirement List Is the Problem

 

Most software development RFP templates lead with a requirements table and tell you to fill it in. That table causes the trouble it is meant to prevent.

A vendor reading three hundred “shall” statements has three options. It can price every line at the pessimistic end and lose on cost. It can price low, win, and recover the gap through change orders. Or it can decline to bid. Careful vendors take the first or third path, which means the sharpest response you get is often the least realistic one.

The 18F field guide states the point in one line. Legacy contract formats that detail hundreds to thousands of requirements up front do not suit the purchase of software development services.

The same guide describes what follows. Requirements get gathered from every stakeholder until scope becomes untenable. The contract is awarded, status charts stay green for two years, and little working software reaches users.

Readers who arrived here shopping for tools to run an RFP process want a different article. Our guide to RFP software categories covers that market. This post is for the buyer writing the document.

Settle Build Versus Buy Before You Write

 

Two projects hide inside most software procurements. One buys a commercial product and configures it. The other builds something bespoke.

The trap sits between them. Teams buy commercial software, then pay to customize it until routine vendor updates no longer apply. The 18F guide has a name for the result: off-the-shelf software modified past recognition. It locks the buyer into a long-term, often sole-source relationship with whoever did the modifying.

Decide which project you are running before the document goes out. Site builds sit in their own category, and our website redesign RFP template covers that variant. If your team will change its process to fit the product, buy the product.

If the product needs changes deep enough to break its upgrade path, you are commissioning custom development and should say so. If the answer is still unclear, an information request costs less than a failed bid. Our comparison of RFI vs RFP covers that call.

The CRAFT Framework for a Software Development RFP

 

At The Write Direction, we work software procurement documents through five sections: context, requirements, architecture, fit, and terms. CRAFT keeps the document focused on things a vendor can price and a buyer can verify.

C: Context. The Problem, the Users, and the System You Have

 

Vendors need your situation, not a wish list.

Describe the current system and what it costs to run. Give user counts by role and peak load. Walk through the workflow being replaced, including the spreadsheet and email steps people use to get around the system today. State the business outcome you want and how you will measure it.

Then check your own readiness. The 18F guide advises validating the path to production before award. It suggests a throwaway prototype as the test. Deploy something trivial and see what happens.

Three conditions tell you the ground is ready. Somebody at your organization administers a hosting environment. Your organization holds its own account on a code repository. Changes to that repository deploy to the hosting environment through an automated process.

Answer those before publishing. A vendor that cannot deploy for two months bills you for the wait.

R: Requirements. Objectives With Acceptance Criteria

 

Write objectives, then the evidence that each one is met.

An objective states what a user needs to do. Acceptance criteria state how you will confirm it. “Applicants can save a partial application and return to it within 30 days” gives a vendor something to build and gives you something to test. “The system shall support session persistence” gives neither.

Set quality conditions that cover all delivered work rather than single features. Common ones: code merged and tested at agreed coverage, accessibility standard met, documentation updated, deployment automated, security scan clean. Publish those in the RFP and they become the standard each demo gets checked against.

Keep the requirements in a separate document that the RFP refers to. Requirements change during a build.

A specification can be revised without reopening the solicitation, and it gives your panel a stable thing to score responses against. Writing that specification is its own discipline, and our software specifications service exists for teams without a business analyst on staff.

For the boundary between the RFP and the work document that follows award, see our comparison of RFP vs SOW.

A: Architecture. Constraints, Integrations, and Hosting

 

Name every system the new software has to talk to, with versions. Say who owns each one and whether an API exists today.

Name your security and accessibility standards. Say which environments you expect and who pays for them. Describe the data you will migrate, its volume, and its condition, since dirty data turns a six-week migration into six months.

Settle hosting in the document. The 18F guide warns against letting the builder also control deployment and hosting.

That arrangement creates a conflict of interest, and opaque deployment steps become another form of lock-in. It recommends defining infrastructure as code, so your servers live in files you own rather than in a vendor’s undocumented setup. Deployment should reduce to a single command your team can run.

F: Fit. Team, Method, and Evidence

 

Software proposals reward writing talent unless you design against it.

Ask for named key personnel and the hours each will spend on your project. Interview those people rather than the sales team. Ask for links to source code repositories showing comparable work. Cap the technical response at a few pages. Length rewards proposal departments over engineering teams.

Ask how the vendor handles the parts kept out of a demo. Incident response, code review, handover when a developer leaves, and the first production bug at 2am.

Publish your evaluation criteria. Technical approach, team, comparable experience, and price cover most software buys. Price should not dominate. Our guide to RFP scoring criteria and scorecards covers weighting and panel scoring.

T: Terms. Pricing Model, Code Rights, and Exit

 

Three terms decide what your award is worth, and each one costs more to negotiate after a vendor has won.

Pricing model comes first. Fixed price works when scope is stable and known, such as a defined integration or a migration with a clear endpoint. Time and materials with a ceiling fits discovery-heavy work.

It needs an engaged product owner on your side, reviewing progress every sprint. Ask bidders to price both ways if you are undecided. Read the gap between the two as a measure of the risk they see.

Code and data rights come next. Say who owns the source code, the infrastructure files, the documentation, and the data. Name the license for anything reused, and confirm the vendor may not resell your custom work. Add an escrow arrangement when a single small firm holds critical code.

Exit terms close the section. Set a transition period with named deliverables: repository access, credentials, documentation, and a working handover to your team or the next vendor.

Modular Scope Beats One Big Award

 

Federal rules solved this problem in a way private buyers can borrow. FAR 39.103 tells agencies to split technology purchases into increments. Each one is easier to manage than a single comprehensive buy.

Each increment has to deliver a workable system. It must perform its main functions without depending on later increments. Contracts must be built so the buyer is not required to buy the next increment at all.

That last clause is the leverage. An increment that stands alone lets you stop, change vendors, or change direction without losing what you paid for.

The rule also sets a clock. Modular contracts should be awarded within 180 days of issue, with deliveries scheduled inside 18 months. Technology moves while procurement deliberates.

18F applies the same logic to sizing. Scope the work so one or two teams can deliver it, and hold the period of performance to three years or less. Avoid folding several teams’ needs into one award, since consolidating contracts hides complexity rather than reducing it.

What to Attach to the RFP

 

Attachments carry the detail so the RFP body stays readable.

Attachment	Why it exists
Requirements or objectives document	Keeps changeable detail outside the solicitation body
Acceptance criteria	Defines “done” before anyone bids
Integration inventory	Lists systems, owners, versions, and API status
Data profile or sample extract	Lets vendors price migration against real volumes
Security and accessibility standards	Names the standards rather than gesturing at them
Pricing template	Forces comparable line items across bids
Draft contract terms	Surfaces code rights and exit terms before award

Pre-Issue Checklist

 

Seven content checks before the document goes out:

1. Build or buy settled, with the customization boundary stated.
2. Path to production validated, with hosting, repository, and deployment confirmed.
3. Objectives written with acceptance criteria, and detail moved to an attachment.
4. Integrations named with versions, owners, and API status.
5. Increments defined so each delivers something usable on its own.
6. Pricing model chosen, with a ceiling if time and materials.
7. Code rights, data rights, and exit terms drafted.

Those cover document content. Run your own procurement rules alongside them.

From Our Client Work

 

See our previous client studies here.

Most teams that come to The Write Direction have the technical knowledge and no time to write it all down. The gap is seldom engineering judgment. It is turning that judgment into language a vendor can price and a panel can score.

Frequently Asked Questions

 

What should a software development RFP include?

 

A software development RFP should carry your business context and current system, objectives with acceptance criteria, and a named technology and integration environment.

Add security and accessibility standards, the delivery approach you expect, team and proof requirements, published scoring criteria, and a pricing template. Close with terms covering code ownership, data rights, and transition. Put changeable requirement detail in an attachment rather than the document body.

How long should a software development RFP be?

 

Fifteen to thirty pages covers most custom builds, with attachments carrying the detail. Length in the body works against you.

A long requirement list invites padded pricing and lets vendors claim compliance without proving capability. Cap the technical response at a few pages so engineering teams write it rather than proposal departments.

Should a software development RFP include a budget?

 

Yes, as a range or a ceiling. Vendors size teams to budget. A range lets them propose scope that fits rather than guess and pad.

A ceiling also filters out firms whose delivery model cannot work at your level of spend. Pair the number with the pricing model so bidders know whether the figure covers a fixed scope or a not-to-exceed engagement.

Is fixed price or time and materials better for software development?

 

Fixed price suits work with a stable, knowable scope, such as a defined integration or a data migration.

Time and materials with a ceiling suits discovery-heavy builds. It needs a product owner on your side, reviewing progress each sprint. Requesting both prices in the same RFP software development process reveals how much risk each bidder sees in your scope.

Who owns the source code after a software development project?

 

Whoever the contract names, so settle it in the software development RFP. Without a clause, ownership often stays with the vendor, along with the infrastructure files and documentation.

State in the RFP that your organization owns the source code, the deployment configuration, the documentation, and the data. Name the license for any reused components, and add escrow when one small firm holds business-critical code.

Write the Document Before You Write the Cheque

 

A software development RFP earns its keep by making bids comparable and risk visible. Context tells vendors what they are walking into.

Objectives with acceptance criteria replace a feature list vendors cannot price. Architecture names the constraints. Fit surfaces the team behind the proposal. Terms decide what you own when the engagement ends.

At The Write Direction, our team writes RFPs and the documents behind them for organizations buying custom software. That includes the requirements spec and the acceptance criteria. We turn technical judgment your team already has into language vendors can price and a panel can score.

Get the document right before it reaches your vendor list. Book request for proposal assistance with our team, or email [email protected] to talk through your project.