Why Custom Software Quotes Vary So Wildly, and How to Get One You Can Trust

You send the same brief to three development agencies. One comes back at a figure that makes you wince. Another quotes less than half that. The third gives you a day rate with no ceiling and a shrug about how long it might take. Same project, wildly different numbers. So which one is right, and why can none of them agree?

If you have ever searched for what a web app costs in the UK, you already know the honest answer is "it depends". That is true, but it is also a cop-out when it comes with no explanation. The spread in quotes is not random, and it is not always down to one agency being greedy and another being cheap. It comes from a few specific habits in how software gets priced. Once you can see them, you can ask for a quote that means something.

Why the numbers are so far apart

They are quoting before they understand the work

Most quotes are produced after a single call and a quick read of your brief. That is not enough to know what you are actually asking for. A phrase like "a portal where clients can upload documents and see their status" hides a dozen decisions: who can see what, how documents are stored, what "status" means, what happens when something goes wrong. Each of those decisions changes the price. When an agency quotes before working them out, it is not pricing your project. It is pricing its guess about your project.

Optimistic anchoring wins the work

A lower number wins more pitches. Everyone in the market knows this, so there is a quiet pressure to quote the sunniest version of events: nothing goes wrong, you know exactly what you want, no one changes their mind. Real builds are not like that. The low quote that won the work often becomes a series of awkward conversations later, once the optimism runs out and the real cost shows up as extras.

Hourly billing removes the reason to be right

When you are billed by the hour or the day with no ceiling, the estimate is just a conversation starter. It is not a promise. If the build takes twice as long, that is your bill, not theirs. There is nothing dishonest about charging for time worked, but it does mean the person quoting carries none of the risk of being wrong. The incentive to sweat the estimate and get it tight simply is not there.

Undefined scope makes every quote a guess

This is the root of the other three. If no one has written down exactly what is being built, in enough detail that two people would build the same thing from it, then every quote is a guess dressed up as a figure. Scope creep is not really creep. It is the gap between what you pictured and what was ever actually agreed, filling itself in one billed hour at a time.

The fix: pay for scoping before you pay for a build

The way out is almost boringly simple. Before anyone commits to building anything, pay a small fixed fee to work out precisely what needs building. Not a free pitch, where the incentive is to say what wins the work, but a paid piece of work with your genuine problem at the centre of it. A short, focused scoping exercise costs a fraction of a full build and saves you from committing tens of thousands to a guess.

Good scoping is not a sales document. It is the thinking that should have happened before any figure was ever quoted. Done properly, it produces four things worth having.

• A written specification. Plain language, detailed enough that a developer could build from it and you could read it and recognise your own project. This is the artefact that turns a guess into a plan.
• A prototype direction. A clear sense of how the thing looks and behaves, so you are reacting to something concrete rather than imagining from a paragraph.
• A fixed-price quote for the build. A single figure to build what the spec describes, because now there is a real spec to price against.
• Portability. You keep all of it. The spec, the direction, the quote. You are free to build with whoever you like, including someone other than the firm that scoped it.

That last point is the one that tells you whether scoping was done in your interest or theirs. If the output only makes sense as a lock-in to one supplier, it was a sales process wearing a spec as a costume. If you can walk away with everything and take it to another builder, then the work was genuinely about understanding your project. You should insist on it either way.

Why fixed-price only works after scoping

Fixed-price sounds like the obvious thing to want, and it is, but it comes with a catch that matters. A fixed price only protects you if the builder carries the risk of getting the estimate wrong. That is the whole point of it. If the build runs long, that is the builder's problem, not a surprise on your invoice.

For a builder to take on that risk sensibly, the spec has to be real. No one can, or should, name a firm fixed price to build something vague. That is not caution, it is arithmetic: you cannot price what has not been defined. This is why the order matters so much. Fixed-price before scoping is either padded heavily to cover the unknowns, or it is a low number that quietly turns hourly the moment reality bites. Fixed-price after a proper spec is a real commitment, because both sides finally know what they are agreeing to.

So the sequence that gives you a quote you can trust is not complicated. Scope first, for a small fixed fee. Get a real spec. Then, and only then, get a fixed price to build it. Anyone offering you a firm build price before that work has happened is quoting a guess, however confident it sounds.

How Evoloop does this

Evoloop is a Glasgow development studio that builds and runs web apps and internal tools for UK businesses, and this pattern is how the work starts. The Scoping Sprint is one implementation of it. It runs for one to two weeks and costs between £1,500 and £4,000. It ends with a written specification, a prototype direction, and a fixed-price quote for the build. You keep all of it, whether or not you go on to build with Evoloop.

If you do go ahead, the Fixed-Price Build is built at the agreed figure and you own the code outright. After launch, a Run & Improve retainer covers hosting, security, backups and small changes, so the thing you paid to build keeps working rather than slowly rotting. The point of the sequence is not the labels. It is that every number you are asked to commit to sits on top of a real spec, priced by someone who carries the risk of having got it wrong.

The next time three quotes land on your desk at three different figures, you will know what you are looking at. Not three prices for one project, but three guesses of varying optimism. The one worth trusting is the one that comes after the work of understanding what you are actually building. That work has a name and a modest price, and it is the cheapest insurance you will buy on the whole project.