The head of procurement at a mid-sized distribution company in the Netherlands opens three proposals for a new partner portal. The first comes in at €95,000, the second at €180,000, the third at €350,000. All three respond to the same twelve-page document. The board wants to know where an almost fourfold difference comes from and which vendor is trying to take advantage.
The answer is less dramatic than the board would like. Most likely nobody is taking advantage of anyone. The first vendor priced a portal with login, a catalogue and an order form. The second added an ERP integration, because the document said “the system should work with our existing systems”. The third assumed real-time two-way synchronisation, a separate mobile app and high availability, because that is how it read the word “modern”. Each priced a different project, because the RFP allowed each of them to invent one.
This article is for whoever has to write a request for proposal (RFP) for custom software or evaluate the responses that have already arrived. It covers what the document must contain, how to describe scope so vendors price the same thing, how to build evaluation criteria and weights, which buyer-side mistakes inflate the price and how to recognise a bid that is cheap only until the contract is signed. The argument is simple: the quality of the proposals you receive mirrors the quality of the request you sent.
Why does the RFP set the price before the vendor calculates it?
Because pricing software is largely pricing uncertainty. A vendor reading your RFP does two things: it estimates the work it understands and adds contingency for what it does not. The more gaps the document has, the bigger the second part. A vague sentence in an RFP is not neutral. It costs money.
The scale of that uncertainty in IT projects is well documented. A 2012 study by McKinsey and the University of Oxford covering more than 5,400 IT projects found that large projects (initial budgets above $15 million) ran on average 45% over budget and delivered 56% less value than predicted (McKinsey, 2012). An experienced bid team facing a foggy scope therefore protects itself with a higher price or a long list of exclusions.
A vendor has three ways of reacting to a gap in the RFP, and each costs you. It can add contingency, in which case you pay for a risk that may never materialise. It can take the cheapest interpretation and write an exclusion, in which case the bid looks attractive and the difference returns as change requests. Or it can price the broadest interpretation so that nobody can later accuse it of missing something, in which case you overpay for scope you do not need. The three proposals in the opening example are exactly those three reactions.
A good RFP does not remove uncertainty; with custom software that cannot be done before work starts. But it turns hidden uncertainty into visible uncertainty. Instead of “the system should work with our existing systems” you write “integration with the ERP through its existing REST API: stock levels read every 15 minutes, orders written in real time, around 2,000 orders a day”. The vendors can still get the estimate wrong, but all three are wrong about the same task.
When do you need a full RFP, and when will an RFI or three conversations do?
A full RFP is an investment: several weeks of work on your side and on the vendors’ side. It does not always pay off. Three tools are worth telling apart.
An RFI (request for information) asks the market who does similar work, how they would approach it and what cost range such projects usually fall into. An RFI does not end in a selection. It ends in a shortlist and a better understanding of what you are actually buying. It makes sense when you do not yet know whether you need custom software or a configured off-the-shelf product, or when you have no reference point for the budget.
An RFP (request for proposal) is the real thing. You describe the problem and the scope, expect a proposed solution, team, timeline and price, and score the responses against published criteria. It makes sense when the project is large enough that the difference between vendors is worth tens or hundreds of thousands of euros, when your procurement policy requires a documented selection, or when several departments need to agree on what they actually want.
Conversations with three firms without a formal document work for smaller assignments, for adding a few specialists to an existing team, or when fit between people matters more than comparing concepts. If you need two developers to join your team, a twenty-page RFP is overkill. A skills profile, a rate and technical interviews will do.
There is also a middle path that works better than anything else when uncertainty is high: an RFP for a discovery phase. Instead of asking for a price for the whole system, which nobody can give honestly, you ask for a price for a few weeks of pre-implementation analysis that ends with a scope, an architecture and an estimate for the rest. You choose a vendor for discovery and decide on the full build with documents in hand that you paid for and own. Our guide to custom software development covers the whole journey from discovery to maintenance.
A simple test: if you cannot describe in one paragraph what the system should do and for whom, you are not ready for a full RFP. Start with an RFI or a request for discovery.
What must a custom software RFP contain?
A good RFP has a stable structure. The order of the sections is not sacred, but leaving any of them out almost always shows up in the proposals.
- Context and business goal. Who you are, what problem the system solves and how you will know it worked. Success measures, even approximate ones: shorter order handling time, fewer calls to customer service, entry into a new market. A vendor who knows the goal can propose a cheaper route to it.
- Users and processes. Who will use the system, how many of them there are, what the main scenarios are. A short description of the process “today” and “after go-live” is worth more than a feature list.
- Functional scope with priorities. Features grouped by importance (method below), with a clear list of what is out of scope.
- Non-functional requirements. Performance, availability, security, accessibility, legal requirements. With numbers, not adjectives. Our glossary entry on non-functional requirements explains how to write them.
- Technical landscape. Systems to integrate with, their interfaces and owners, preferred hosting, company technology standards, data to migrate.
- Constraints. The deadline and what depends on it, the budget or its range, sector regulation, security team requirements.
- Preferred engagement model. Fixed price, time and materials, a team subscription or openness to the vendor’s proposal.
- Non-negotiable contract terms. Assignment of intellectual property, repository access from day one, confidentiality, rules on subcontractors. Better that the vendor knows about them before pricing than after selection.
- Response template. A single format: pricing table, team description, timeline, assumptions and exclusions, answers to questions.
- Evaluation criteria and weights, plus the process timeline. Question deadline, submission deadline, presentations, decision date.
The sections most often skipped are 1, 8 and 9. Without a business goal, vendors price the feature list literally. Without the non-negotiable terms, you pick a bid that later turns out more expensive because the vendor charges extra for the IP assignment or refuses repository access. Without a response template you receive three documents with three structures: one quotes a total, another quotes rates and estimated hours, a third quotes only phase one. Comparing them takes longer than writing the RFP did.
How do you describe scope so vendors price the same thing?
Scope is the section that drives the spread of prices more than any other. Three techniques narrow it considerably.
First: MoSCoW priorities. Every feature gets a category: must have, should have, could have, won’t have this time. You ask for separate prices for “must” and “should”. That way you see not only the total but also the price of the smallest version you could go live with, and you can decide whether the second group is worth its price. A vendor who prices everything as one block takes that decision away from you.
Second: scenarios instead of adjectives. “An intuitive admin panel” cannot be priced. “An administrator adds a partner, assigns a price list from one of five discount groups and grants access to selected product categories; the operation takes under two minutes” can be priced and can be checked at acceptance. A description like that is also the seed of the acceptance criteria that will later go into the contract.
Third: numbers wherever scale changes the architecture. Concurrent users, transactions per day, data volume to migrate, number of languages, number of roles with different permissions, required availability. A system for 50 internal users and a system for 50,000 end customers are two different projects even if the list of screens is identical. If you do not know the exact number, give a range and a horizon: “300 partners today, up to 1,500 in three years”.
What is not in scope matters just as much. An explicit “out of scope” list (a mobile app, a payments module, migrating data from before 2020) prevents one vendor from pricing it while another does not. If a feature is uncertain, name it and ask for a separate line item. An option priced separately does not distort the comparison; an option quietly included by one bidder does.
Which constraints and context do buyers most often leave out?
This part of the RFP is rarely interesting to write and very often decides the cost. Five gaps come up again and again.
Integrations described in one sentence. Integrations are one of the most common sources of overruns in custom projects, because their cost depends on things the vendor cannot see: whether the target system has a documented API, whether anyone on the client side understands it, whether a test environment exists, whether the target system’s vendor has to change anything and how long that takes. For each integration, state the system and version, the communication method, the direction and frequency of data exchange, the volume, the availability of a test environment and a named contact.
Data to migrate. Where it comes from, how much there is, what state it is in. A data migration the vendor hears about after signing is the classic change request.
Technology and hosting constraints. If your IT department requires a specific cloud, a specific language or compliance with internal security standards, say so. A vendor who proposes something else will have to change it anyway, only after selection and at extra cost.
Regulatory requirements. Personal data and GDPR, sector rules in finance or healthcare, the European Accessibility Act, security obligations for products with digital elements under the Cyber Resilience Act. Each translates into work: security testing, documentation, logs, reviews. Better to have it in the proposal than in a change request.
Your own involvement. Who will own the product, how much time they have, how quickly you will answer questions and sign off milestones. A vendor who knows there is a product owner available half-time on the client side prices differently from one who assumes every decision will take a week. Waiting for client decisions is, under a fixed price, a risk somebody has to price.
The budget deserves its own paragraph. In private procurement it is worth disclosing, at least as a range. The fear that vendors will “fit the budget” is understandable, but in practice it works the other way round: the budget tells vendors what project to design. At €80,000 they will propose a different architecture and a different first release than at €400,000. Without that information every vendor guesses, and the spread of the bids reflects the guessing.
What should you ask vendors so their answers can be compared?
The response template is the cheapest investment in the whole process. Instead of asking for “a proposal”, you ask vendors to fill in specific fields. We suggest five blocks.
Block 1: understanding of the problem. One page in which the vendor describes in its own words what it understood, which risks it sees and what it would need to price more confidently. That page says more about the vendor than the whole “about us” section. If a vendor sees no risks in a project you consider difficult, either it has not read the document or it does not want to worry you before signing.
Block 2: pricing in a single structure. A table broken down by phase or module, “must” and “should” separately, options separately. For each line: person-days by role and the day rate. Plus explicit contingency, if the vendor uses it. We cover how to read that kind of breakdown, and what to check in it, in our article on how software houses price a project.
Block 3: assumptions and exclusions. A list of everything the vendor assumed that was not in the RFP and everything it did not price. This is the most important part of any proposal and the one most often ignored in evaluation. Two bids with the same price and different exclusions are two different prices.
Block 4: the team. Who exactly will work on the project, in which roles, with what experience and at what allocation. Whether the people in the proposal are the people you will see in the project, and what happens if one of them leaves. The replacement terms matter more here than the CVs.
Block 5: ways of working. Iteration length, how often you see working software, reporting, change management, engineering practices (automated tests, code review, CI/CD), client access to the repository and tools.
Add a few closed questions that expect “yes” or “no” with a comment: do you accept assignment of all IP in the code upon payment for each milestone; will the repository sit in our organisation from day one; do you use subcontractors; do you accept the contract template in the appendix. Questions like these surface deal-breakers before you invest in evaluation.
How do you build evaluation criteria and weights?
The criteria must be published in the RFP before any proposal arrives. Setting them after opening the bids always ends with criteria that fit the favourite, even if nobody planned it that way.
The most important decision is the weight of price. For custom software, the proposal price is a weak predictor of project cost, because the final cost depends on how the vendor handles change, quality and risk. Public procurement law reached a similar conclusion. Article 67 of the EU public procurement directive requires contracts to be awarded on the most economically advantageous tender, assessed on a price-quality basis, with the weighting of each criterion stated in advance (Directive 2014/24/EU). In the UK, the Procurement Act 2023, applied from 24 February 2025, moved to the “most advantageous tender”, deliberately dropping the word “economically” (Procurement Act 2023, s. 19). A private company is not bound by either, but the logic carries over well to buying software. For projects with uncertain scope, a sensible weight for price is 30–40%.
The remaining criteria fall into four groups:
- Quality of the solution and understanding of the problem. Does the proposal address the business goal, has the vendor identified the risks, is the architecture proportionate to the scale (neither too thin nor over-engineered)?
- Team and its stability. Experience of the people named in the proposal, replacement terms, ratio of senior to junior engineers.
- Ways of working and transparency. Demos of working software, repository access, reporting, change management, quality practices.
- Contract terms and risk. Acceptance of key clauses, engagement model, warranty period, ease of exit.
Each criterion needs a scoring scale with a description of what 1, 3 and 5 mean. “Team: 5 points if every key role has a named person with experience on a similar project and the vendor commits to their participation; 3 points if key roles are named without commitment; 1 point if the team is described only by roles.” Without such descriptions, the score depends on the evaluator’s mood.
Score price relative to the budget or the median, not linearly against the cheapest bid. The formula “lowest price gets full marks, the rest proportionally” rewards an extremely cheap bid and penalises honest ones. If one bid is clearly underpriced, it sets the scale for everyone.
What does a sample proposal scoring matrix look like?
The matrix below is a starting point to adapt to your project. The weights are our recommendation for a custom build with moderate scope uncertainty, not a market standard. The “warning sign” column helps evaluators who are not engineers.
| Criterion | Weight | What earns 5 points | Warning sign (1 point) |
|---|---|---|---|
| Total price of the “must” scope | 30% | Within budget, broken down by role and person-days, explicit contingency | A single figure with no breakdown, or a price a third or more below the median with no explanation |
| Understanding of problem and risks | 15% | Vendor named risks, asked questions, proposed simplifications | No risks, the RFP repeated back, “we can do everything” |
| Assumptions and exclusions | 10% | Complete list, consistent with the RFP, no key items excluded | No list, or integrations, testing or deployment excluded |
| Team | 15% | Named people in key roles, replacement terms in writing | Team described by role only, mostly junior |
| Ways of working and quality | 10% | Demos every two weeks, automated tests, code review, CI/CD, repository owned by client | First demo after several months, no access to code |
| Contract terms | 10% | Accepts IP assignment, acceptance, warranty and exit terms | Licence instead of assignment, no handover plan |
| References on a similar project | 5% | Call with a client of similar scale and integrations | Logos only, no consent to contact |
| Pilot or workshop result | 5% | Working slice or solid workshop output | No participation, or a sales pitch instead of work |
If two bids differ by a few percentage points, treat it as a tie and settle it with a pilot or another round of questions, not arithmetic. The matrix structures the discussion; it does not replace judgement. Write down the reasoning behind each score, because halfway through the project your board will ask why you chose this vendor.
Which RFP mistakes push the price of proposals up?
Part of a project’s cost is created in the document before any vendor sees it. Seven mistakes come up most often.
1. Fixed price on a vague scope. Asking for a fixed price for a system described in a few pages is asking for a price on risk. A vendor taking on scope risk adds a premium for it, and that is rational. If scope is uncertain, ask for a fixed price for discovery or the first phase and use a transparent rate for the rest. For a detailed comparison of who pays for uncertainty in each model, see team subscription, T&M or fixed price.
2. Adjectives instead of numbers. “Scalable”, “secure”, “fast”, “modern”. Each word has to be turned into a number by the vendor, and each vendor will choose a different one. A cautious vendor will choose a high number and price an expensive architecture.
3. A deadline that is too short. One week to respond to an RFP for a large system means vendors cannot ask questions, so they add contingency for everything they do not understand. For a mid-sized project, two to three weeks is the realistic minimum, including a week for questions.
4. No question-and-answer round. Questions asked by one vendor and answers shared with all is the cheapest way to narrow the spread. Without it, each vendor interprets the document alone.
5. Hidden contract terms. If a contract template with liquidated damages, unlimited liability or a long warranty appears only after selection, the vendor will either raise the price in negotiation or walk away. Either way you lose time. Show the key terms in the RFP. We describe what they should cover in our article on software development contract clauses that protect the client.
6. Disproportionate formal requirements. Bank guarantees, high professional indemnity cover, certifications the project does not need, long declarations. Each adds cost to the price and fewer firms respond. Require what protects the project, not what was in the template from a different tender.
7. Sending the RFP to too many firms. Ten bidders means each has roughly a 10% chance of winning. Vendors know this and invest proportionally less: instead of an architect, a salesperson answers with a template. Three to five carefully chosen vendors produce better proposals and less evaluation work.
All seven have one thing in common: they push onto the vendor work or risk that the buyer could carry more cheaply. The vendor will not refuse. It will send an invoice for it.
How do you recognise an underpriced bid that gets expensive after signing?
The cheapest bid is not always a trap. Sometimes the vendor has a ready component that shortens the work; sometimes it understood better what does not need to be built. But there are signals worth checking before you treat a low price as a bargain.
A price far below the others with no explanation. EU public procurement rules require contracting authorities to ask a bidder to explain its price when a tender appears abnormally low (Article 69 of Directive 2014/24/EU). Polish public procurement law even sets a numeric trigger: a price at least 30% below the average of the bids or the estimated contract value. That works as a rule of thumb in private procurement too: a bid a third below the median calls for a conversation, not congratulations.
No assumptions and exclusions, or a very long list of exclusions. The first means the vendor has not thought the project through; the second means it thought it through very carefully and cut everything expensive. Look especially for excluded integrations, data migration, testing, production deployment and documentation.
Very little effort for work “around the code”. Testing, project management, analysis, deployment, fixes after acceptance testing. If coding is almost the whole bid and the rest are token lines, that work will still be done, only through change requests or at the expense of quality.
A strict change procedure. If the bid is cheap and the definition of a change is broad, with every change separately priced, the vendor’s business model may rely on change requests. Ask for a sample estimate of a typical change and the rates that will apply to it.
When you see these signals, do not reject the bid automatically. Ask for clarification: a breakdown, the assumptions and a comparison with your own reading of the scope. An honest vendor with a low price can defend it. A vendor who answers “why so cheap?” with “because we are efficient” usually recovers the difference later.
How should you run the process: deadlines, questions, presentations and a paid pilot?
The process matters as much as the document. A typical sequence for a mid-sized project looks like this.
Week 0: shortlist. Pick three to five vendors based on an RFI, recommendations, public references or initial calls. Sign an NDA before sharing details.
Week 1: issue the RFP and take questions. Vendors have a week for written questions. You publish the answers to everyone at the same time without revealing who asked. If the questions show something in the document is unclear, fix it and send out a new version.
Weeks 2–3: proposal preparation. Optionally, one session with each vendor where its architect can probe technical details. It is a good investment: a conversation replaces a dozen assumptions.
Week 4: written evaluation. Each panel member scores independently against the matrix. Then a joint session and a list of follow-up questions for each vendor.
Week 5: presentations. Ideally with the people who will actually work on the project, not just the sales team. Instead of a company pitch, ask them to walk through the three biggest risks in your project and how they would manage them. Ask a question the RFP does not answer well and watch how the team reasons.
Optional weeks 6–9: a paid pilot. When two vendors score alike, the most reliable tie-breaker is a short paid piece of work: discovery, a prototype of a key scenario or a small, self-contained slice of the system. It costs a fraction of the project and shows what no proposal can: how the team asks questions, how quickly working software appears and how it reacts when you change your mind. Agree up front that the pilot output belongs to you whoever wins.
Switching vendors mid-project means a code handover, rebuilt knowledge and months of delay. Five weeks of careful selection is cheap insurance.
What should you do with the result to move from evaluation to contract?
Choosing a vendor is not the end of procurement work. Two steps protect the value the RFP created.
Write the proposal into the contract. The assumptions, exclusions, team and timeline from the proposal should become contract schedules. If the vendor promised named architects in the proposal and the contract only mentions “suitably qualified personnel”, the promise has no force. The same goes for contingency and the rates for change requests.
Turn the scope into a plan for the first phase. Whatever the engagement model, the first phase should end with a working, accepted slice of the system within weeks, not months. The first acceptance is when you see whether the proposal’s assumptions hold, and it is the cheapest moment to correct course.
It also pays to calculate the total cost of the choice, not just the proposal price: maintenance after go-live, licences, infrastructure, your own team’s time on the client side. A higher build price with a lower running cost often wins over five years. Our article on total cost of ownership shows how to calculate it.
What are the key takeaways?
An RFP for custom software is the first document of the project, not a procurement formality. Most of the price spread that buyers later blame on vendors is created in it.
Remember six things. First, every gap in the document costs money, because the vendor either adds contingency or takes the cheapest interpretation and recovers the difference through change requests. Second, describe scope with priorities, scenarios and numbers rather than adjectives, and say clearly what is out of scope. Third, disclose the budget or its range and the contract terms that are non-negotiable. Fourth, insist on a single response template with a pricing breakdown, assumptions, exclusions and a named team. Fifth, publish criteria and weights before opening the bids, keep price at around a third of the score and score it against the budget or the median, not the cheapest bid. Sixth, treat a bid a third below the rest as a reason to ask questions, and settle ties with a paid pilot.
A good RFP does not guarantee a successful project, but it makes sure you are comparing bids for the same project. That is the only condition under which choosing a vendor is a real choice.
A word on how this looks from our side. In custom software development we start with a discovery phase that usually takes one to two weeks and defines the scope and the architecture. We work in two-week sprints with working increments from the start, and price on a fixed-price or time-and-materials basis depending on how well the scope is defined; fixed-price projects are delivered against milestones. When scope is uncertain, we recommend starting with a short pilot rather than pricing the whole system from a few pages of description. Our indicative rates by role and seniority are published, so you can compare them with the bids you receive, and for an MVP the MVP cost calculator gives you a first range.
If you are preparing an RFP and want to check whether it is ready to send, or you already have proposals and cannot explain the differences between them, book a call. We will tell you plainly what the request is missing and whether, in your situation, a full RFP, a request for discovery or simply a few conversations will work best.