Software RFP: template, scoring, and a required response format

A software RFP is a document that describes the project and sets the rules of the round at the same time: the layout suppliers have to answer in, the criteria you will score them against, and the date you stop accepting replies. The usual reason for a bad choice is not the price — it is that three offers arrive in three different layouts and cannot be lined up row by row. What follows is the structure of that document for an ordinary private company, a ready paragraph on the required response format, and a table for comparing what comes back.

How a software RFP differs from a brief

A brief describes the project; a request for proposal organises the process of collecting and comparing offers. In practice the RFP has two halves: the descriptive one, which is the brief, and the procedural one — scoring criteria, the required response format, deadlines, and the way questions are handled.

The descriptive half is broken into sections and shown on a filled-in example in the separate guide on how to write a software project brief. This piece is about the second half of the document, the half that decides whether the answers can be compared at all.

The distinction has a practical consequence. You write a brief once and use it for a year; you prepare an RFP for one specific round, with dates, the list of studios you approached, and criteria that apply to that round only.

What sections a software RFP contains

An RFP for a private company has ten sections: the first six are descriptive, and the last four are the ones that make offers comparable.

• Context and problem. What the company does, what does not work today, and what that costs in time or money.
• MUST/SHOULD scope. Features that are mandatory in the first release, kept apart from the ones that can wait.
• An explicit exclusions list. A separate “what this project does not cover” section. It is the cheapest paragraph in the document, because it takes the uncertainty buffer out of the estimate.
• Systems to integrate with. Names and versions, whether they expose an API, and who on your side has access to them.
• Constraints. Hosting, personal data, industry requirements, technology already in use in the company.
• Budget and deadline. A range, plus a date with the reason it matters: a trade fair, a supplier contract ending, a change in the law.
• Scoring criteria with weights. The list of factors, with percentages, that your decision will follow.
• Required response format. A numbered list of the points the offer has to be presented in.
• Submission deadline and method. A date with a time, an email address, a file format.
• Contact person. One person, and the date after which you stop taking questions.

If the descriptive half does not exist yet, work through the goal, the scope and the constraints with someone who will ask about all of them — tell us what you are planning and use the write-up as the opening sections of the RFP.

The required response format: the section most RFPs are missing

The required response format is the list of points every supplier has to present its offer in, in the same order and with the same breakdown. Without it you receive three documents built around three different ideas of what matters, and you end up comparing other people’s assumptions rather than prices.

The mechanism is simple. A studio arranges its offer to show off its strengths: one writes up its methodology, another gives you a single figure and three sentences, a third lists technologies. All three can concern the same project and all three will look incomparable, because each stays silent about something different.

Force the format with seven points:

1. Itemised pricing — modules or functional areas, each with its own effort estimate and its own amount.
2. Assumptions made — what the supplier assumed wherever the RFP said nothing, because that is exactly where later disputes start.
3. An out-of-scope list — what does not fit inside the quoted amount; demand this point even when you listed exclusions yourself.
4. A schedule with milestones — stages, dates counted from contract signature, and the dependencies on your side.
5. The team — roles, headcount, how much of their time you get, and who actually writes the code: employees, contractors, or subcontractors.
6. Billing model and payment terms — with the reasoning behind the choice and the scope-change procedure.
7. Warranty, support and rights to the code — the warranty period, response times, the documentation handed over, and how rights are transferred.

Add one control question to point one: are project management, testing, post-launch support, and tool licences inside the price. Those four items are the ones that most often come back later as an extra cost, simply because the first version of the offer never mentioned them. What else that figure is made of is broken down in the guide on mobile app development cost.

Announcing that incomplete offers go back for completion is not a threat, it is information. A firm that had no intention of breaking down its estimate drops out on its own — which is useful, because you would meet the same approach later at invoicing time.

Scoring criteria: weights instead of impressions

Scoring criteria are a list of factors with weights adding up to 100%, published in the RFP rather than settled after the offers are opened. They do two jobs at once: the supplier knows where to put its effort, and you have a ready justification for the decision in front of your board or your co-owners.

A sample set for a software rollout: fit of the proposed solution to the business goal 35%, price together with the completeness of the estimate 25%, experience with similar integrations 20%, schedule and team availability 10%, warranty and maintenance terms 10%. Set the weights against what is genuinely risky in your project — if all the risk sits in exchanging data with an old system, integration experience is worth more than price.

List separately the conditions that disqualify an offer from the round — for example an unwillingness to transfer economic rights to the code, or an inability to keep data on servers inside the European Union. A disqualifying condition is not a scored criterion, so keep the two lists apart.

How to line offers up row by row

Offers are compared in a single table where the rows come from your required response format and the columns are the individual suppliers. An empty cell then means a specific question to ask before deciding, not an absence of information.

Come back to one of those rows before you sign anything: how the work is settled. Whether fixed price or time and materials is right for you is decided by the maturity of the scope, not the size of the project — and that question is worth settling before you compare figures produced under two different models.

The last step is a conversation with the two strongest firms about the discrepancies in the table. The signals that tell you which supplier can actually deliver are covered in the separate guide on how to choose a software house.

How many offers to collect and how to run the question window

Three to five offers are enough, as long as they all come back in the same layout. Below three you cannot see the spread of assumptions; above five the comparison costs more time than it is worth.

Run the question window through one channel: one contact person, a question deadline set a few days before the submission deadline, and a stated rule that every answer goes to all the studios you approached, in identical wording. Without that rule, some suppliers price the project on information the others never received.

Give the submission deadline with a time and a form — a PDF file to a named email address, for example. Add how long your decision will take: suppliers can then plan team availability, and you do not lose the best offer to two weeks of silence.

What not to copy from public-tender templates

Forms published for public procurement — in Poland, the ones used in tenders and in the Baza Konkurencyjności database — are written under a different legal regime and are not a model for a private company. Copying them adds declarations and annexes that protect nobody and can put smaller teams off replying. A private company chooses its supplier freely, so its document should force comparability rather than reproduce a procedure.

Two things belong in the procedural half no matter how informal the round is. The first is confidentiality: sign the NDA before you hand over confidential information — pricing structure, client lists, personal data, code, or internal documentation — at the latest before the discovery call where the studio gathers the details for its offer. Describing the problem and its scale rarely involves such data, so the first enquiry does not have to wait for signatures.

The second is rights to the code. Paying an invoice does not transfer economic copyright: that needs a contract, and under Polish law — art. 53 of the Act of 4 February 1994 on copyright and related rights, which applies when you contract a studio operating in Poland — such a contract requires written form on pain of invalidity. In the RFP one sentence is enough: that you expect the transfer of rights together with the listed fields of exploitation, plus handover of the source code and documentation. The clauses themselves are unpacked in the guide on who owns the code. This material is information, not legal advice — agree the exact wording with a lawyer.