Software Development RFP Template (Free, Word): Custom Apps

About this template: Use this RFP to hire a software development
company, such as an agency or development partner, to design, build,
launch and support a custom application. It isn’t for buying software
that already exists. Fill in the [square brackets], and replace the
example entries, which describe a booking and field service app, with
your own. Delete the italic instructions before you send the RFP, and
have legal counsel review Sections 9 and 15 and your draft contract
first.

1. Introduction and
background

1.1 About us

[Two or three sentences: who you are, what you do, where you operate
and how large you are.]

1.2 Background and the
problem

[Describe the problem the software will solve: how the work is done
today, which systems are involved, who is affected and why you’re acting
now.]

Example: Customers book service visits by phone and can’t see
when a technician will arrive, so the call center spends much of its day
answering status questions. Technicians receive job details by
email.

1.3 Purpose of this RFP

[Organization name] (“we”, “us”) invites proposals from software
development companies to design, build, test and launch [short
description of the application], and to support it after launch. We
intend to select one development partner (the “vendor”) through the
process in Section 14. This RFP is not an offer and does not commit us
to award a contract.

1.4 Attachments

2. Objectives

List the outcomes you want, in priority order. Describe results
rather than features, and say how you’ll know you’ve achieved each
one.

3. Scope

Give vendors the figures they’ll size and price against. A vendor
that has to guess will either add contingency or leave work
out.

3.1 Users

3.2 Platforms

3.3 Integrations

3.4 Data

• Records and volumes. [Main records, e.g. customers,
  visits, jobs, photos, invoices; numbers at launch, growth per year and
  peak transactions per hour.]
• Personal and sensitive data. [Types of personal
  data, and any regulated data such as payment, health or financial
  information.]
• Migration. [None / Migrate [records] covering
  [number] years from [current system]. State who extracts and cleans the
  data.]
• Location and retention. [Regions where data must be
  stored and processed; how long records are kept.]

3.5 In scope

1. Discovery: [a prioritized backlog, user journeys,
   architecture and a refined estimate].
2. Design: [UX and UI design for each platform,
   following our brand guidelines].
3. Development: [the applications, APIs and
   integrations in Sections 3 and 4].
4. Testing: [as in Section 7, including support for
   our user acceptance testing].
5. Infrastructure: [environments, CI/CD and
   infrastructure as code in our cloud account].
6. Launch: [app store submission under our accounts,
   and production deployment].
7. Handover: [documentation, runbooks and knowledge
   transfer].
8. Warranty and support: [as in Section 11].

3.6 Out of scope

• [Example: Hosting fees, which we pay directly to the cloud
  provider]
• [Example: Changes to the ERP itself]
• [Example: Content writing and translation]

3.7 Phases

Splitting the work into phases lets you fix the price of what you
can define now and keep options open for the rest.

We may [award Phase 1 only and decide on Phase 2 after reviewing the
discovery outputs / award Phases 1 and 2 together]. Our target start
date is [date], and we need the first release live by [date, and the
reason].

4. Functional requirements

Write each requirement as a user story (who needs to do what, and
why) or as a single requirement line, one need per line. Mark each one
Must-have (in the first release and in the price) or Nice-to-have
(priced as an option or planned for later). Keep the Must-have list
short. Replace the example rows with your own.

4.1 Response codes

Give each requirement in Sections 4, 5 and 10 one of these codes, and
explain it in the comment column.

Product RFPs use codes such as standard, configuration and
roadmap, because they ask about a product the vendor already sells.
These codes show instead how each requirement will be built, who owns
that part and whether it’s in the price.

4.2 Requirements

4.3 Acceptance criteria

Add acceptance criteria to the stories that carry the most cost
or risk. They tell vendors what “done” means, and they become the tests
you’ll use to accept the work.

Example for FR-03:

• Given a visit that starts more than [24] hours from now, when the
  customer chooses a new available slot, then the visit moves to that
  slot, the old slot is released and the customer receives a
  confirmation.
• Given a visit that starts within [24] hours, when the customer opens
  it, then the reschedule and cancel options are hidden and the app shows
  our phone number.
• Every change appears in the visit’s history with the date, time and
  who made it.

5. Non-functional
requirements

The bracketed values are placeholders, not recommendations. Set
targets that fit your users and budget, because each one affects the
price.

Public bodies: check whether a law or policy sets the
accessibility standard you must meet, and use that version and
level.

6. Technical constraints

Separate firm constraints from preferences. A preferred stack
helps if your own team will maintain the code, but don’t rule out a
better proposal by prescribing technology you don’t need to.

In your proposal:

• Recommend an architecture and technology stack, and explain why it
  suits our requirements and our team. Where you depart from a preference
  above, explain the benefit and the effect on maintaining the code.
• If we have no mobile preference, recommend native or cross-platform
  development and explain the trade-offs.
• Describe the environments you’ll set up (for example development,
  test, staging and production) and who pays for each.
• List any proprietary platform, low-code product or paid tool your
  approach depends on, with its license terms and its cost to us after the
  contract ends.

7. Delivery approach

Answer each question in no more than [300] words.

• D1. Method. Describe your delivery method (for
  example Scrum or Kanban) and how you’d run it for this project. How many
  hours a week do you need from our product owner?
• D2. Discovery. What does your discovery phase
  produce, how long does it take, and who takes part?
• D3. Sprints and demos. State your sprint length,
  and confirm that you’ll demonstrate working software at the end of every
  sprint in an environment our team can use.
• D4. Estimates and changes. How do you estimate and
  track progress, and how early will you warn us if the timeline or budget
  is at risk? How do you handle changed requirements under a fixed price
  and under time and materials?
• D5. Definition of done. Provide your definition of
  done. It must include at least the items listed after these
  questions.
• D6. Testing. Describe your unit, integration and
  end-to-end testing; performance, security and accessibility testing;
  testing on real devices; and how you’ll support our user acceptance
  testing.
• D7. CI/CD and releases. Describe your pipeline:
  automated builds and tests on every change, code review, deployment to
  each environment, infrastructure as code, release approval and
  rollback.
• D8. Reporting. What will you report, and how often?
  Include progress against the backlog, budget used against the estimate,
  risks and decisions you need from us.
• D9. Launch and handover. Describe your launch plan,
  including app store submission, and the documentation and knowledge
  transfer you’ll provide so that our team, or another supplier, can run
  and change the software without you.

Our minimum definition of done. A user story is done only when:

• the code has been reviewed by a second developer and merged through
  the pipeline;
• its automated tests pass, and no existing tests fail;
• it meets its acceptance criteria and has been demonstrated to our
  product owner;
• it is deployed to the [staging] environment, with accessibility and
  security checks passed;
• affected documentation is updated; and
• no [Severity 1 or 2] defects are open against it.

8. Team and staffing

Ask for the people who will do the work. Vendors can add
rows.

Attach a short résumé for each named person, covering similar
projects and the technologies you propose.

• Key personnel. The [delivery manager, technical
  lead and lead designer] may not be replaced without our written
  approval, except for reasons outside your control, and any replacement
  must have equivalent experience.
• Working hours. At least [number] hours of overlap
  each working day with [time zone].
• Location. State where each person will work.
  [On-site attendance is required for [workshops / launch / none].]
• Subcontracting. Name every subcontractor and
  freelancer, their work and their location. Don’t subcontract beyond what
  your proposal names without our written approval. You remain responsible
  for subcontractors’ work.
• Background checks. [Required, where local law
  allows, for anyone with access to production systems or personal
  data.]

9. Intellectual
property and source code

Agree your position with legal counsel before you issue the RFP,
and put the final terms in the contract. Who owns software depends on
what the contract says and on the law that applies, so don’t assume that
paying for development makes you the owner. This template isn’t legal
advice.

Confirm that you accept each position below, or list your exceptions
in Section 16.

9.1 Custom work

[Option A: We will own the source code, designs, documentation and
other materials created for us under the contract (the “custom work”)
from [creation / payment], and you will sign any documents needed to
confirm that.]

[Option B: You will own the custom work and grant us a [perpetual,
irrevocable, worldwide, royalty-free] license to use, copy, modify and
maintain it, and to have other suppliers do so for us. [State whether
the license is exclusive, and whether you may reuse the custom work for
other clients.]]

Keep one option. Option A suits software that’s core to your
business, or that your own team or another supplier will maintain. A
vendor may price Option B lower if it can reuse the work.

9.2 Pre-existing materials

List any code, frameworks or tools you already own and plan to
include in the software (“pre-existing materials”). You keep ownership
of them, and grant us a [perpetual, irrevocable, royalty-free,
non-exclusive] license to use, modify and maintain them as part of the
software, and to have other suppliers do so for us, including after the
contract ends. [Deliver them as source code.]

9.3 Source code and accounts

• All source code, build scripts, infrastructure-as-code files and
  automated tests are committed to our repository from the first sprint,
  with full history, and we can build and deploy the software using your
  documentation.
• Cloud, app store, domain and third-party service accounts are held
  in our name. Credentials and signing keys are handed over to us.

9.4 Open-source and
third-party components

• List every open-source and third-party component with its version
  and license before the first release, and update the list at each
  release. [Provide it as a software bill of materials (SBOM) in SPDX or
  CycloneDX format.]
• Don’t include components under [licenses on our restricted list,
  e.g. licenses that could require us to publish our own source code]
  without our written approval, and tell us about any component that needs
  a paid license.

Some open-source licenses attach conditions, such as making
source code available, when you distribute software that includes the
component or, under some licenses, when users interact with a modified
version over a network. Have counsel review the license list against how
you’ll use and distribute the software.

9.5 Source code escrow

Keep this only if the vendor will own the code or a platform it
depends on, or will host the software. If all the code is in your
repository (9.3), you may not need escrow.

[State whether you will deposit the source code and build
instructions with an independent escrow agent, how often deposits are
updated and verified, the events that release the code to us (for
example insolvency or the end of support), and who pays the escrow
fees.]

9.6 AI coding tools

State whether your team uses AI coding assistants, which ones and
under what controls. Confirm that code produced with them is covered by
the terms above and reviewed and tested like any other code, and that
our code and data won’t be used to train AI models.

10. Security and data
protection

If you have a security questionnaire, attach it, and keep this
table for the points you’ll score.

11. Warranty and
post-launch support

11.1 Warranty and hypercare

• For [90] days after [go-live / final acceptance], you will fix at no
  charge any defect, meaning a failure of the software to meet the
  accepted requirements, acceptance criteria or documentation, within the
  targets in 11.2.
• The warranty doesn’t cover changes we request, or problems caused by
  changes someone else makes. [List any other exclusion you propose.]
• [For [number] weeks after launch, members of the delivery team stay
  on the project to monitor production, fix defects and support our staff.
  State who, and for how many hours.]

11.2 Defect severity and
targets

State the hours of cover for each severity, for example business
hours, or around the clock for Severity 1.

11.3 Ongoing support
(optional)

Propose support after the warranty period, priced in Section 12.5.
Cover defect fixes against the targets in 11.2, security patches and
dependency updates, updates for new iOS, Android and browser versions,
hours for small enhancements, and handover to us or another supplier
when support ends.

12. Pricing

Delete the tables you don’t need before you issue the RFP.
Keeping both 12.2 and 12.3 for the build shows you how each vendor
prices risk, not just effort.

• Price in [currency], excluding taxes, using the pricing workbook
  (Attachment B) without changing its rows or columns.
• List every assumption your price depends on, such as our product
  owner’s availability, the readiness of the systems you’ll integrate
  with, or the number of design rounds.
• Payment terms: [Net 30] days from a correct invoice. [Fixed price:
  on accepted milestones. Time and materials: monthly in arrears against
  approved timesheets.]
• [Our budget range for Phases 1 and 2 is [range]. / We are not
  sharing a budget at this stage.]

Sharing a budget range stops vendors proposing something you
can’t afford; holding it back keeps prices from clustering just under
your number. Public bodies: check whether your rules cover disclosing an
estimate.

12.1 Phase 1: Discovery
(fixed price)

12.2 Phase 2 option A: Fixed
price

Link each payment to a milestone that’s met only when its
deliverables are accepted. A holdback released at final acceptance gives
the vendor a reason to finish well: fill in the holdback percentages
before you issue the RFP, or delete that column.

State what the fixed price includes, such as the number of design
rounds, and how you’ll price changes.

12.3
Phase 2 option B: Time and materials with a not-to-exceed amount

Under time and materials you pay for the time worked, so ask for
budget used in every sprint report, approve timesheets, and keep the
right to reprioritize or stop work at the end of any sprint.

12.4 Other costs

12.5 Support after the
warranty period

State the minimum term and notice period for each option.

13. Vendor questions

These questions show how the vendor works. Keep the ones that
would change a score.

Answer each question in no more than [300] words.

1. Describe two or three projects you’ve delivered that are similar to
   ours in size, platforms or industry: the client’s goal, what you built,
   the team size, how long it took, and whether it finished on the original
   budget and timeline. If it didn’t, explain why.
2. Which of our requirements carry the most risk, and how would you
   reduce that risk during discovery?
3. What would you put in the first release, and what would you move to
   a later one?
4. List the assumptions and exclusions behind your estimate. What most
   often causes change requests on projects like ours?
5. Describe a project that went badly: what happened, what it cost the
   client, and what you changed afterwards.
6. [Walk us through the repository, tests and pipeline of a past
   project you’re allowed to show, or provide a code sample.]
7. Provide [three] references from the last [three] years with projects
   of similar scope, including one where you handed the software over to
   the client’s team or another supplier.

14. Evaluation criteria and
weights

Set the criteria and weights before any proposal arrives, and
don’t change them afterwards. Public bodies: your rules may require you
to publish the criteria and their relative importance, so check with
your procurement office.

14.1 How we will evaluate
proposals

1. Compliance check: each proposal arrived on time, is
   complete, and accepts this RFP’s terms or lists exceptions.
2. Independent scoring: each evaluator scores their
   sections against the criteria below before the panel meets to agree
   scores. [Cost is reviewed separately.]
3. Presentations: [two or three] shortlisted vendors
   present with the team named in Section 8, [including a walkthrough of a
   past project].
4. References and selection: we check references and
   select the vendor with the highest total score, subject to agreeing a
   contract.

14.2 Criteria and weights

These weights are an example only. Adjust them to your priorities
before you issue the RFP: if your own team will maintain the code, for
example, you might move weight toward technical quality and
handover.

To compare a fixed-price bid with a time-and-materials bid, use
the same scope: compare the fixed price with the not-to-exceed amount,
and read the assumptions behind each. A fixed price with long
exclusions, or a low estimate with a high not-to-exceed amount, can cost
more in the end.

14.3 Scoring scale

• 5 Excellent: fully meets the criterion, with
  specific evidence from similar work, a demonstration or a
  reference.
• 4 Good: meets the criterion, with clear evidence
  and minor gaps.
• 3 Adequate: meets most of the criterion; gaps have
  a credible plan.
• 2 Weak: misses important parts, or the answer is
  vague.
• 1 Poor: doesn’t address the criterion, or no
  answer.

Weighted score for each criterion = score × weight ÷ 100. Because the
weights total 100, the highest possible total is 5.00.

Decide how you’ll turn prices into a cost score before proposals
arrive, and use the same method for every vendor. The RFP evaluation
criteria guide compares the common methods.

15. Submission
instructions and timeline

15.1 Timeline

An example schedule. For a mid-sized software RFP, a response
window of three to four weeks is a workable example; allow more if you
want detailed estimates.

15.2 How to submit

• Deadline and place. Submit by [date, time and time
  zone] to [email address / portal name and link], with the subject line
  “RFP [number]: [Vendor name]”. Proposals received late [will not be
  considered / may be rejected].
• Format. One PDF for the written proposal, plus
  Attachments A and B completed in their original format. Follow this
  RFP’s section order and numbering, and answer each requirement and
  question against its ID. [Page limit: [number] pages, excluding
  résumés.]
• Validity and costs. Proposals and prices remain
  valid for [90] days after the deadline. You bear your own costs of
  responding.

15.3 Questions and
communication

• Send questions in writing to [RFP contact email] by [date, time and
  time zone]. We will send every question and answer to all vendors,
  without saying who asked.
• Changes to this RFP will be issued as numbered addenda. Acknowledge
  each one in your proposal.
• Until we announce a decision, contact only the RFP contact about
  this RFP.

15.4 Terms of this RFP

Have your legal or procurement team confirm these terms before
you issue the RFP.

• This RFP is not an offer or a commitment to award a contract. [We
  may award all, part or none of the work, and may cancel this RFP.]
• The contract will be [the draft contract in Attachment D / our
  standard terms]. [Commitments in your proposal may be included in the
  contract.]
• Treat this RFP and its attachments as confidential, and use them
  only to prepare your proposal. [As a public body, we may be required to
  disclose proposals under public records laws. Mark confidential material
  as this RFP allows.]

16. Exceptions and signature

List any exception to the requirements, Section 9, Section 15.4 or
the draft contract, with the wording you propose instead. Write “None”
if you have no exceptions.

By signing, I confirm that I am authorized to submit this proposal on
behalf of the vendor named below, that the people named in Section 8
will work on the project if we are selected, and that the information in
this proposal is accurate.