Seven Questions That Explain the Gap Between Quotes

Three numbers for the same job usually mean three different jobs.

Seven things move a software estimate, and for each one there is a question that reveals whether it is in the number in front of you. Ask the seven and the quotes stop being a price comparison and become a scope comparison - which is the only comparison that tells you anything.

What is already established

Two things are worth knowing before the drivers, and neither is ours.

The first is that divergence usually has a mundane cause. One firm we read names three: the suppliers read the requirement differently, someone estimated naively in one direction or the other, or someone bid low deliberately to win the work. Only the last is dishonest, and it is the least common of the three.

The second is that a confident single fixed price for a project nobody has scoped is a warning sign rather than reassurance. A UK firm puts it almost exactly that way - a fixed price after a thirty-minute call is a red flag - and another flags the same risk through the scope disputes and change orders that follow. This is now common advice and we will not spend the page on it. It is right, it is theirs, and the more useful question is what to do next.

That question is where the published material stops.

The seven drivers

These are the things that actually move the number. The first four are usually the largest.

Integration surface. How many other systems must this touch, in which direction, and how well do they behave? One-way export into a spreadsheet is trivial. Two-way sync with a system that has no proper interface is the single most expensive thing on most projects.

Data migration. What has to come across, in what state, and who decides what “right” looks like when two sources disagree. Migration is priced by how messy the existing data is, which nobody knows until someone looks.

Roles and permissions. Whether everyone can do everything, or whether there are approval gates, restricted views and audit requirements. The gap between “one user type” and “four with different visibility” is much larger than it sounds.

Compliance and data handling. Whether the work touches personal, financial or regulated data, and what has to be provable rather than merely true. This is rarely the biggest cost but it is the most commonly discovered late.

Testing depth. Whether the supplier is pricing “it works when we try it” or automated coverage that keeps working after the next change. Both are legitimate; they are not the same product.

Deployment and environments. Whether there is a staging environment, whether releases are automated, whether anything is monitored. A cheap quote and an expensive quote often differ mostly here, invisibly.

Support after launch. Whether the number includes the weeks after go-live when real use finds real problems, and on what terms.

An existing framing we read covers roughly this ground from the supplier’s side - scope clarity, seniority, design, QA, project management, documentation, deployment and support. Ours is organised around what a buyer can ask about rather than what a supplier does.

The question that exposes each

This is the part we could not find anywhere. Naming drivers is common; turning each into a question a non-technical owner can ask, and knowing what a thin answer sounds like, is not.

Driver	The question to ask	What a thin answer sounds like
Integration surface	”Which systems does this read from or write to, and which direction does each go?"	"It integrates with your existing tools” - no named systems, no direction
Data migration	”What data comes across, and who decides what is correct when two sources disagree?"	"We’ll migrate your data” with no mention of cleaning, mapping, or who arbitrates
Roles and permissions	”How many kinds of user are there, and what can each not see or not do?"	"Role-based access is included” without the roles being named
Compliance	”What in this touches personal or financial data, and what would we need to be able to prove?”	Silence, or a reference to being “GDPR compliant” with nothing specific
Testing depth	”What is tested automatically, and what is checked by a person before release?"	"Fully tested”
Deployment	”Is there a staging environment, and how does a change get to live?"	"We handle deployment”
Support	”What happens in the four weeks after launch, and is it in this number?"	"Support is available” - available and included are different words

Send these in writing to every supplier. The replies are more informative than the quotes, because a supplier who has priced a driver can describe it in a sentence, and one who has assumed it away has to decide what to say.

The two drivers nobody lists

Of the pages we opened on 24 August 2026, data migration and compliance appear in none of the published driver sets. One eight-driver framing omits both entirely; the closest UK competitor does not name either.

That is a strange pair to lose, because in our experience migration is the single most common source of a surprise invoice. It is invisible in a demonstration, it is impossible to size without looking at the actual data, and it is the one item where the honest answer before inspection is a range rather than a number.

Compliance is quieter but has a similar shape: it rarely dominates a budget, and it is very often discovered after the design is settled, at which point accommodating it costs more than it would have at the start.

If a quote does not mention either, it has not necessarily excluded them. It has probably not thought about them, which is worse, because an exclusion is visible and an oversight is not.

Your own process is a cost driver

Here is the driver that is never on anyone’s list, because suppliers are reluctant to say it and buyers do not expect to hear it: how settled your own way of working is changes the price.

If the same job is done three ways depending on who does it, the supplier must either build for all three, pick one and be wrong for two, or stop and help you decide. All three cost money. The first two also produce software people quietly work around.

This is why the same brief can honestly attract very different numbers from suppliers with different assumptions about how much of that work is theirs. A supplier who intends to settle your process with you is quoting a larger job than one who intends to build exactly what you described, and neither is wrong - but you should know which one you are buying.

The question to ask yourself, before asking anyone else anything: could two people describe this workflow the same way today? If not, part of every quote you receive is a guess about how that gets resolved.

How we handle a gap

Rather than generalise about suppliers, here is what we do when a driver is unknown at quoting time, so you can ask others the same thing.

We ask, if the answer is cheap to get - which systems, which data, who approves. That costs a day and nothing else.

We give a range with the reason attached, if the answer could plausibly go two ways. A range with a stated cause is an honest number; a range with no explanation is padding.

We assume and write the assumption into the proposal, if resolving it would take you weeks. This is the one that can cost you later, because an assumption you did not read is a boundary you did not agree to.

What we avoid is a single confident number against an unscoped brief - for the reason a UK competitor already published, and because we would then have to defend it by argument rather than by evidence.

Why this page gives you no numbers

You will notice there are no rates here, no ranges, and no “typical cost of a small business system.”

That is deliberate. The figures available to us came from single sources without stated method, usually attached to something being sold, and the surrounding territory is full of rate tables that were accurate in some market at some point and are quietly wrong now. A page whose argument is that benchmarks mislead cannot lean on benchmarks.

What is durable is the structure: which things move a number, and how to find out whether they are in yours. That does not date the way a day rate does.

What the questions cannot tell you

Three limitations.

They cannot tell you whether the work will be done well. Every driver above can be priced honestly by someone who then builds something poor; that is what references and a small first phase are for.

They cannot resolve a genuine difference of professional opinion. Two suppliers can disagree about how much testing this deserves, and both be reasonable. The questions make the disagreement visible; they do not settle it.

And they assume you can describe the work. If you cannot yet, the gap in your quotes is mostly a gap in the brief, and that is a different job to do first.

What to do with three quotes this week

Send the seven questions to all three suppliers in one email each, identically worded. Do not explain why you are asking.

Put the answers in a table with the drivers down the side. You are looking for two things: the driver where the answers differ most, which is where the money is; and the driver where one supplier said nothing, which is where the risk is.

Then ask each of them what it would cost to include what they left out. When those numbers come back, compare the totals - and not before.

FAQ

One quote is half the others - should I discard it? No, ask it the seven questions. Half the price is usually half the scope, and the answers usually show which drivers were assumed away. Occasionally the cheap quote is the only one that read the brief properly and the others padded; you cannot tell which without asking.

Should I tell suppliers my budget? Yes, as a range. Withholding it does not protect you from being overcharged - it produces proposals aimed at the wrong size of problem, and you pay for the mismatch in wasted rounds.

Why will you not tell me what this costs? Because any number we gave you without seeing your integration surface, your data and your permissions would be a guess dressed as information, and you would compare real quotes against it. The seven questions get you to a real number faster than a benchmark would.

Is a day rate a fair way to compare? Only alongside scope. A higher day rate that includes testing and deployment maturity can produce a lower total than a cheaper one that does not, and comparing rates alone reliably favours whoever included least.

Notes

• Live result set retrieved 2026-08-24 (en, GB proxy) via requests req_4bbc5e785e83 and req_d117a263f759, both at zero budget. Three pages opened and read in full. See research/live-result-set.md.
• The fixed-price warning and the three causes of divergence are established published advice, credited in §2 rather than claimed. The eight-driver supplier-side framing is another firm’s and is noted as such.
• What we did not find in any opened page: a mapping from each driver to a question a non-technical owner can ask, data migration and compliance as named drivers, and the buyer’s own process maturity as a cost input. Those observations are scoped to the three pages we opened, not to the whole market.
• The seven drivers, the questions, and the ask/range/assume account of our own estimating are Garaxe’s, described as we genuinely use them. No client outcome, win rate or success claim is made.
• This page deliberately publishes no rates, ranges or cost benchmarks. Figures were available in the opened set; they are single-source, method-unstated, attached to products being sold, and dating. Reproducing them would contradict the page’s own argument.
• No AI-assistant answer baseline was collected - the probe was unavailable on 2026-08-24.
• Autocomplete returned no suggestions and no People-Also-Ask questions were returned, so this page makes no claim about what buyers search for.