Software quotes: why three prices come back so far apart
Three quotes for the same internal system come back far apart because each vendor read a different amount of coupling in your operation. The price does not measure the size of the screen. It measures how many things the vendor thinks they will have to touch for that screen to work. The spread is information about your request.
Why do three vendors read the same request and answer with such different prices?
Because your request describes the screen and their price describes what sits behind it.
"We need an order system" is a complete sentence for the person running the operation and an ambiguous one for the person pricing it. It does not say whether the order starts with a field rep or the customer, whether stock has to answer in real time, whether price comes from a table or a per-customer rule, whether the invoice is issued from the same place. Each vendor answers those questions alone, silently, and charges for the answer they gave.
The cheap one usually answered "this is a data entry screen". The expensive one usually answered "this touches stock, finance and invoicing". Both are quoting honestly. They are quoting different projects.
So the spread is not a market problem. It is a picture of how much went unsaid in your request.
What does the research say about cost risk in software?
That the risk does not live in the average. It lives in the tail.
Bent Flyvbjerg and colleagues compared 23 project types in a study published in 2026, with 5,360 IT projects in the sample. IT projects go over budget in 40.86% of cases, one of the three lowest frequencies in the whole table. Buildings overrun in 73.66%. Tunnels, 73.91%. Nuclear power, 96.94%. The Olympics, 100%.
That first number contradicts the common belief that software always slips and always costs more. Most of the time, the budget holds.
The second number is the one that matters. Among IT projects, 18.26% run more than 50% over, and in those cases final cost averages 5.53 times the original estimate. That 5.53 is the highest of the 23 types compared, above nuclear waste storage, above defense, above the Olympics. The same table shows the statistical signature: in IT, mean overrun sits 73 percentage points above the median.
Translated into your decision: the odds of the budget holding are reasonable, and the bill on the day it does not hold is of a different order of magnitude. Choosing a vendor on price alone optimizes the easy half of the problem.
Where does the tail come from?
From coupling. The work that unpacked the mechanism behind that distribution comes from the same research group and runs on the same base of IT projects, in a cut of 5,392 projects. These are not two independent pieces of evidence, they are two views of one dataset. The explanation they propose is interdependence between components: a problem in one part sets off a chain reaction in the parts wired to it, and that propagation is what produces the extreme overruns.
That study carries two findings worth keeping. The first is that overruns and underruns appear with similar frequency, which reinforces that the initial estimate is a range and not a number. The second sits in a footnote: the largest overrun in the entire sample was not a megaproject. It was a small workflow customization, budgeted at 1,500 dollars, that ended at 425,000 dollars.
Keep that pair together. Small scope plus coupled operation is the combination that produces the large bill. And an operation that has accumulated systems bought in different eras is exactly where coupling lives unseen.
Which is why the right question before comparing prices is not "what does this cost to build". It is "how many things does this touch".
Who is reading the proposal on your side of the table?
In many companies, nobody whose job that is.
Eurostat data for 2025 shows how technical capacity inside the company scales with size. Among EU enterprises with 10 or more people, 33.02% run data analytics with their own employees. Split by size, that is 27.86% for small enterprises of 10 to 49 people and 78.84% for large ones. The same gap shows up in business software: 41.08% of small enterprises use an ERP package, against 88.71% of large ones.
Those indicators measure capability in the company, not the reading of a technical proposal. They point in one direction anyway. The smaller the buyer, the less in-house technical capacity sits on their side of the table, and the quotes arriving are written to the same standard either way.
In most mid-sized companies this role has no declared owner on the org chart. You can cover that gap without hiring anyone, as long as you change what you ask for.
How to compare three quotes that are not measuring the same thing
Ask each vendor for the list of what they will touch. Not the feature list, which everyone writes the same way. The list of systems, spreadsheets, routines and people that have to change behavior for the new system to work.
Four questions account for most of the spread:
Which systems that already exist here does this proposal read from or write to? Anyone answering "none" is proposing one more island, and islands are cheap on delivery and expensive over three years.
What happens when one of those systems changes or goes down? The answer separates whoever thought about coupling from whoever will find out during the project.
Which part of this proposal is an assumption and which part is a commitment? An assumption nobody labeled as one becomes a change order later.
What was deliberately left out? A senior vendor answers that quickly and with a list. Anyone without the list drew no boundary at all.
If the three answers come back different, you do not have three prices. You have three scopes, and now you can pick which one is yours.
A scenario to make this concrete, offered as a working hypothesis and not as a measurement of any client of ours: a distributor with 60 employees asks for an order system. Vendor A quotes the order screen and the list. Vendor B includes reading stock in real time. Vendor C includes stock, the per-customer pricing rule and the invoicing trigger. The three prices will land far apart, and none of the three is wrong. What is wrong is the request that allowed three readings. Half an hour drawing the boundary before asking for quotes moves more money than any negotiation afterwards.
Drawing that boundary is the same discipline that sets what it costs to keep a system running after delivery, and the one behind architecting internal systems against bottlenecks. In the rescue of the Colo Saúde platform, the first project was not a build: it was a security audit and a performance tune-up on an inherited platform that had no technical owner.
Yowpi issues quotes too, and the four questions above work on ours exactly as they work on anyone else's. A proposal that does not survive them does not deserve a signature, whoever sent it.
Frequently asked questions
The cheapest quote proposes no-code. Is the price difference just the tooling?
Rarely. The tooling explains part of the difference and the scope boundary explains most of it. Compare what each proposal touches in your operation first. If both vendors reach the same set of systems and routines, the comparison between approaches becomes honest, and at that point it is a legitimate technical decision.
Integration with what I already run will be complicated. Does that show up in the quote?
It does, almost always as an assumption. Look for lines like "assuming the ERP exposes an API" or "assuming database access is granted". Each of those is a risk parked on your side without being priced. Ask for every assumption to come with what happens if it does not hold.
I have no qualified staff to evaluate a technical proposal. What do I do?
You do not need to evaluate the architecture. You need to compare scopes, and you do that better than any vendor, because you know the operation. Ask the four questions in this article in writing and read the answers the way you read a process description. Wherever the answer goes vague about what the system touches, that is the risk.
The next step
If you have proposals on the table and prices that do not agree with each other, the Operational Architecture Diagnostic is a 30-minute conversation to draw that boundary before you sign. Bring the quotes.
Related case studies
Did you recognize your operation in this article?
Book the Operational Architecture Diagnostic: 30 minutes to map where your operation's bottleneck is. No proposal in the first conversation.
Book a diagnostic