Almost everyone who has commissioned software has a story about the final bill. The usual explanation is that developers are optimistic, which is true and not much use to you.
More usefully, most overruns are decided in the first fortnight rather than the last one, before anybody has written a line of code. Here is where they tend to come from.
The quote covered a description, not a decision
Somebody asks for a booking system and gets a price for a booking system. Then the questions start. Can 2 people hold the same slot? What happens to a cancellation inside 24 hours? Does a deposit come back automatically or does somebody approve it? None of that was in the description, all of it has to be decided by someone eventually, and every answer carries a cost whether or not it was in the original number.
So look at whether the quote lists the decisions that have already been made or just the outcome you asked for. A quote that reads back to you like your own wish is not really a quote yet.
Nobody looked at the data you already have
Migration is the most routinely underestimated part of any project, because real business data has 15 years in it: the same customer entered 4 times, addresses living in a notes field, a status code somebody invented in 2019 and never wrote down. Building the system is fairly predictable work. Getting your actual data into it is not, and it is frequently the thing that moves a launch date.
Worth finding out whether anyone has opened the data or has only been told what is in it.
The integration was assumed to be easy
"It needs to talk to our accounts package" can mean a documented API and 2 days, or it can mean the vendor charges for API access, rate limits it, and does not expose the one field the whole thing depends on. The gap between those is enormous and entirely knowable in advance by somebody spending an afternoon checking, which is why "should be fine" is the phrase to push back on.
Changes had no process
Some scope change is healthy and you should expect it. You see the thing working, you understand it better than you did in a meeting, and you want it different.
It turns into an overrun when those changes get absorbed informally, one small yes at a time, with nobody counting until the invoice. Ask what happens when you want something changed, and listen for whether you see the cost before the work happens or afterwards.
The estimate had no slack
An estimate carrying no allowance for the unknown is not confidence, and every project has surprises in it, so a quote that pretends otherwise is a quote you will end up renegotiating.
There is also a real difference between work a company has done 30 times and work it is attempting for the first time. Estimates are reliable where there is experience behind them and speculative where there is not, so it is worth asking how much of your project is familiar ground for whoever is putting the number together.
How we do it
We spend longer before quoting than most people expect, because the first fortnight is where overruns get prevented rather than explained afterwards.
Scope gets written down before the price, in ordinary language: what we are building, what it does, what it costs, and you approve that before anything starts. Changes are priced rather than absorbed, so if you want something added in week 5 you see the number before we build it and nothing lands on an invoice you have not agreed to.
A large part of the work is familiar ground for us. We build on BadgerFramework, our own codebase of features already written and running in production, so the predictable parts of your project are genuinely predictable to us, which is what makes a fixed price honest rather than hopeful.
We look at the awkward parts first, which means your existing data and the systems you need to talk to get examined before we quote instead of discovered in week 6.
Because we host and support what we build, any corner cut during the build becomes our problem for the next 5 years, and that does more for quality than any promise in a proposal. A dedicated team stay with the project from the first conversation through to running it, so there is no handover point where the knowledge falls out, and you do not pay until you are happy with what we have built.
It does mean we occasionally have to tell somebody their project is bigger than they were hoping, which is a far better conversation at the start than at the end and is the reason our quotes hold.