Software development RFP template, with a completed example and a vendor scorecard

What is a software development RFP template, and what goes in a completed one?#

A software development RFP template is a request for proposal filled in for one real project, sent with the weighted scorecard that will rank every bid that comes back. The scorecard is not an extra. In fact, the US Federal Acquisition Regulation (FAR), in the version effective 13 March 2026, makes it part of the request: "All factors and significant subfactors that will affect contract award and their relative importance shall be stated clearly in the solicitation" (FAR 15.304).

You do not have to be a federal agency for that rule to help. Because vendors write to the criteria they can see, a request with hidden weights gets bids that answer different questions. Then nothing lines up when you try to compare them.

So a completed template carries three kinds of decision. First, it states what you need, in enough detail that two vendors would price the same thing. Second, it fixes when and how bids arrive, so that each vendor gets the same window. Finally, it says how bids will be scored before any of them is read.

What follows takes those decisions in order. It explains the document, lists its sections, and then fills every section for a dispatch app replacement. After that come the response window, the weights, the scorecard and a question bank.

What is RFP in software development, and when does an RFI or RFQ fit better?#

In software development an RFP asks vendors how they would solve a defined problem and at what cost, so it fits work where the approach matters as much as the price. That is the job FAR Part 15 gives it. There, the RFP is the solicitation used when an agency negotiates rather than simply takes the lowest quote.

The tradeoff process in FAR 15.101-1, effective 13 March 2026, is the reason to use one. It "permits tradeoffs among cost or price and non-cost factors and allows the Government to accept other than the lowest priced proposal". In short, you can pay more for a better team, as long as you wrote down why.

Two other documents sit beside it. First, a request for information (RFI) gathers market facts before you commit. FAR Part 15 says RFIs suit an agency that "does not presently intend to award a contract" and wants "capabilities for planning purposes". Second, a request for quotation (RFQ) asks only for a price on a scope already fixed, such as licenses or a known block of hours.

So the choice rests on how settled the scope is. If you cannot yet describe the problem, send an RFI. If the scope and the method are both fixed, an RFQ is enough. But if the scope is clear and the way to build it is open, the RFP is the right document.

What does a software request for proposal template contain, section by section?#

A software request for proposal template needs nine sections, and the three that published RFPs never skip are the schedule, the evaluation criteria, and the price format. Each section exists to make bids comparable.

Three public software RFPs show the pattern. The Clean Power Alliance RFP of 16 September 2022 is short. Even so, it prints a dated schedule, its evaluation criteria and a pricing section. In addition, the IUCN RFP for its grants portal, June 2025, and the Hampton Roads Workforce Council RFP of 25 May 2026 attach a weight to every criterion. However, the Clean Power Alliance lists its three criteria without weights, which is the one gap among the three.

Here are the nine sections, in the order a vendor reads them:

1. Company background. Who you are, who uses the system, and who decides.
2. Project goal. The business outcome, stated as something you can measure.
3. Scope and requirements. What must be built, and what is out of scope.
4. Current systems and integrations. What the new software must talk to.
5. Deliverables and acceptance. What you receive, and how you will test it.
6. Schedule. The release date, question deadline, due date and decision date.
7. Budget and price format. Your range, and the shape every price must take.
8. Evaluation criteria and weights. How bids will be scored, published in advance.
9. Submission rules and contract terms. Format, page limits, ownership and warranty.

The first five sections define the work. However, only sections 6 to 8 make bids line up, and they are the ones a blank template leaves emptiest.

What does a completed request for proposal for software development look like?#

Here is a completed request for proposal for software development: a regional field-services company replacing its dispatch and scheduling app, every section filled the way you would send it. The company is invented, and so are its figures. Still, the level of detail is the point, because no list of section names can show it.

1. Company background. We run heating and plumbing repair across two states, with about 60 field technicians and a dispatch desk of six. Our operations director owns this project and signs the contract.

2. Project goal. Cut the time from a customer call to a confirmed technician slot to under ten minutes, and end double bookings. Today dispatchers plan routes on a whiteboard and a spreadsheet.

3. Scope and requirements. Build a web dispatch board and a mobile app for technicians. The board assigns jobs by skill, location and open slots. Then the app shows the day's jobs, captures photos and a customer signature, and works offline in basements. Billing and payroll stay in their current tools and are out of scope.

4. Current systems and integrations. Jobs must sync with our accounting package through its published interface. Also, customer records move once from the current spreadsheet, and every record is checked after the move.

5. Deliverables and acceptance. We want working software every two weeks on a test site we can use. Final acceptance is a two-week trial in which our dispatchers run real days on the new board.

6. Schedule. On day 0, the RFP goes out. On day 7, questions close, and on day 12 all answers go to every vendor. Then proposals are due on day 36. After that, shortlisted vendors demo on day 50, and we decide by day 65.

7. Budget and price format. For this example, say the budget is $300,000 to $450,000. Price every milestone separately, and list the hourly cost of each role for changes after kickoff.

8. Evaluation criteria and weights. Technical approach 35%, relevant experience 25%, key people 15%, project plan 10% and price 15%. We score each criterion from 1 to 5, and price is scored by formula.

9. Submission rules and contract terms. Send twenty pages at most, plus résumés of the people who will do the work. We own the code and data. Defects found in the first 90 days are fixed at no extra cost, and a transition-out plan is part of the contract.

Section 8 borrows the Hampton Roads weights, and section 9 borrows its terms from the US Digital Services Playbook. Next comes where each number came from.

How long should a software development request for proposal stay open?#

Three published software RFPs gave vendors 14, 36 and 49 calendar days from release to the due date, and the longest one also ran a pre-qualification step. Those three windows are the planning figures worth trusting, because each is counted from a dated schedule.

The Clean Power Alliance released its RFP on 16 September 2022 and wanted proposals by 30 September 2022. That gave 14 days for a scope already well described. Next, the Hampton Roads Workforce Council issued on 25 May 2026 with proposals due 30 June 2026, which is 36 days for a full website modernization. In contrast, IUCN published on 12 June 2025 and set its deadline for 31 July 2025. Those 49 days included a pre-qualification round and a sample backlog sent only to bidders who passed.

The longer the window, the more steps it carried. Therefore, match the window to the work you ask for. A narrow scope with no pre-qualification can close in a fortnight. But a build that asks vendors to estimate a backlog needs closer to the IUCN window. The specimen copies the Hampton Roads window, because its scope is of a similar size.

How do published software RFPs weight price against the work itself?#

The Hampton Roads Workforce Council modernization RFP gave price 15 percent of the score and technical approach 35 percent, and stated every weight before a bid arrived. So price was one of five criteria, and tied for the second smallest.

IUCN made the same choice in a different form, in its June 2025 RFP. Its total score is 75% technical and 25% financial. Also, IUCN requires a bid to reach 70% on the technical score before its price counts at all. As a result, a cheap bid with a weak plan never reaches the price stage.

Both follow the rule FAR 15.304 sets for federal agencies, effective 13 March 2026: the factors and "their relative importance shall be stated clearly in the solicitation". So the weights are a promise to each bidder. Once bids are open, changing them is how a fair process turns into an argument.

A practical start is to copy a published scheme and then move one weight with a reason. For instance, the specimen keeps price at 15, as Hampton Roads did. A company with a hard budget ceiling might raise it, but it should do that in writing, before release.

At what price weight does the cheapest bid start to win?#

In the worked example scorecard the cheapest of three bids loses at a 15 percent price weight and only takes first place once price passes about 42 percent of the score. So the weight you give price decides the winner more than any single score does.

Suppose three bids come back for the dispatch app: bid A at $310,000, bid B at $420,000 and bid C at $380,000. Then the panel scores the four non-price criteria from 1 to 5. Bid A scores 3, 4, 4 and 3; bid B scores 5, 4, 4 and 4; bid C scores 4, 4, 3 and 4.

Price follows the formula in the June 2025 IUCN RFP, which divides the lowest price by each bid's price. So the cheapest bid always gets the full price score.

At a 15% price weight in the worked example, bid B wins with 86.1 points out of 100. Bid C follows with 77.2 points, and bid A, the cheapest, comes last with 74.0 points. Then the price weight rises and the other weights shrink in proportion. In this worked example, bid A passes bid C at about 28% and takes first place from bid B at about 42%.

You can check every total by hand. Each score out of 5 is multiplied by its weight and divided by 5. For bid B in the worked example, that is 35, 20, 12 and 8 points, plus 15 times 310,000 divided by 420,000 for price. That price share is about 11.1 points, so bid B totals 86.1.

Check the published examples too, because even careful documents slip. The June 2025 IUCN RFP states 75% technical and 25% financial. Yet its own example works "a total score of 83 * 70% + 77 * 30%" and reaches 81.2%. At the stated weights, the same bid scores 81.5. The gap is small, although a vendor who loses by less than that has grounds to ask which rule applied.

Which RFP questions to ask software vendors, and what does each answer prove?#

The RFP questions to ask software vendors fall into five groups, and each question earns its place only if the answer changes a score on the scorecard. Otherwise a question adds pages and decides nothing.

IUCN shows the habit well, in its June 2025 RFP. It sent pre-qualified bidders a sample product backlog and weighted their answer on it at 30% of the technical score, the largest single item.

Here is a question bank for the specimen, grouped by the criterion each answer feeds:

• Technical approach (35). How would you build the offline mode for technicians, and what would you test first? Which parts of our list would you push back on, and why?
• Relevant experience (25). Show one scheduling or field-service system you shipped. What broke after launch, and how did you fix it?
• Key people (15). Who exactly will do the work, and how much of their week is ours? What happens if one of them leaves?
• Project plan (10). What will we see working at the end of the first month? How do you handle a change request, and who approves it?
• Contract and exit. Who owns the code and data? How long is the warranty? What is in the transition-out plan?

The last group mirrors the US Digital Services Playbook, read on 4 October 2026. Its contracting checklist asks that software and data a vendor produces "remains under our control". It also asks for a warranty period, and it checks that the "Contract includes a transition of services period and transition-out plan". So score those answers under the project plan, or make them pass or fail.

How do you adapt the RFP template for application modernization vendors?#

An RFP template for application modernization vendors adds three things to a new-build RFP: an inventory of the current system, a data migration requirement, and a transition-out plan. That is because the risk in a modernization sits in the old data and in the people who use the old system every day.

The Hampton Roads Workforce Council RFP of 25 May 2026 shows the first two in practice. It makes the vendor "responsible for 100% content inventory and selective migration". It also asks for a content audit "identifying pages to migrate, consolidate, rewrite, or retire". Finally, it requires a 301-redirect mapping for every retired address, so old links still work.

For an application rather than a website, the same additions become concrete asks. First, describe what the current system does, including the reports someone runs once a quarter. Second, require a migration plan with a dry run, a count of records before and after, and a rollback step. Then ask for the transition-out plan the Digital Services Playbook names, so the next vendor can take over.

Score the migration plan as part of the technical approach, not as an extra. In the specimen, item 4 already asks for every customer record to be checked after the move. So a modernization RFP turns that one line into its own scored criterion.

When is a formal RFP the wrong tool for a software project?#

A formal RFP is the wrong tool when the scope is still a guess, because vendors then price their guesses and a paid discovery phase would answer the question faster. Bids built on different guesses cannot be compared, however good the scorecard is.

Three cases call for something else. First, if you cannot yet write section 3 of the template, send an RFI, which FAR Part 15 treats as a request for planning information, not an offer. Second, if you need to learn what to build, pay one team for a short discovery phase that ends in a written scope. Then send that scope out as an RFP. Finally, if the work is small and the approach is obvious, ask two or three firms for a quote and check their references.

The tradeoff process in FAR 15.101-1 assumes the requirement is clear enough to weigh price against quality. Without that clarity, the weights in section 8 measure guesswork. In short, the better RFP is sometimes the one you send three months later.

Where to go next once the RFP is ready to send#

Once the RFP and scorecard are ready, the next decisions are the budget range you state and the shortlist of companies you send it to. Each has its own guide.

For the budget line in section 7, how much custom software development costs walks through what drives the range. For the shortlist, how to choose a custom software development company covers reference calls and the final pick. If the project replaces an old system, choosing a legacy modernization partner adds the migration checks.

If your scope is not settled yet, our product discovery page describes what a discovery phase produces. And if you want a custom software development company to answer the RFP, that page explains how we respond.

Still, the template above is enough on its own. Copy the nine sections, keep the weights you can defend, and publish them before the first bid arrives.