You send the same one-paragraph brief to three developers. The numbers come back nowhere near each other — not a little apart, a lot. One is a fraction of another for what reads, on paper, like the identical project.
You didn’t send different briefs. So why does the number swing so wildly?
They didn’t price the same project. They priced three different guesses about what you actually meant — and the gap between those guesses is where a budget goes to die, usually a few months in, in the form of a change order nobody warned you was coming.
Before any of this: is custom even the right call for what you need? An honest framework for build vs buy answers that question first. This guide assumes you’ve already settled it — and you’re now holding quotes that disagree with each other.
What the spread is actually telling you
A quote isn’t a price. It’s a bet on how much the unwritten parts of your brief are going to cost. The developer with the low number is betting there aren’t many unwritten parts. The one with the high number is betting there are plenty, and pricing in the padding to survive finding out. Neither has seen inside your business yet. Both are guessing — one optimistically, one defensively.
The real project usually sits somewhere between the low guess and the high guess. Almost never at either end. That’s not a comforting average — it means the number you eventually pay depends on how much of the guessing you remove before anyone starts building.
The cost drivers you can actually move
Most of what makes custom software expensive isn’t the code. It’s the parts of the job nobody wrote down. Four drivers account for most of the swing between quotes — and all four are yours to move, before a single line gets built.
Scope clarity
“We need a booking system” is not a scope. It’s a category. A developer pricing a category has to guess at the details — how many staff, what happens on a cancellation, does it need to send a reminder — and every wrong guess becomes a change order later, billed at a worse rate than the same detail would have cost as a line in the brief. Writing a brief that describes outcomes instead of features is the one hour, before you request a quote, most likely to change what number comes back.
Integrations
Every other system your new software has to talk to — your accounting tool, your booking calendar, a supplier’s ordering platform — is a separate unknown, with its own documentation quality and its own chance of quietly not working the way its docs claim. A project that touches one system is a different project from one that touches five, even when the feature list looks identical on paper.
Edge cases
The happy path — everything filled in correctly, nothing unusual happening — is the cheap 80%. The other 20% is what a refund looks like, what happens when a card expires mid-transaction, what the system does with a customer who somehow ends up with two accounts. Developers who price fast are usually pricing the happy path only. The edge cases show up later, as scope you get told you forgot to mention.
Who owns the accounts
This one is invisible on a quote and expensive later. If a developer sets up hosting, the code repository, and your API keys — the credentials that let two systems talk to each other — under their own accounts “to make things easier,” easier for whom, exactly? That’s a dependency that never showed up as a line item, and its price stays hidden until the day you need to fire them, or they vanish, or “easier” quietly becomes a monthly fee to keep the lights on in their account. Getting the ownership question answered before invoice one won’t change today’s number. It changes what it costs you to ever leave.
What a suspiciously low quote is actually telling you
A number well under the others isn’t a gift. It’s information. It usually means one of three things: the edge cases haven’t been scoped yet and you’ll discover them on your own dime; the number quietly excludes testing, documentation, or deployment and is a partial figure wearing a full one’s clothes; or the plan is a template or no-code tool that will hit a ceiling the day your business does anything slightly non-standard.
None of those three automatically disqualify a quote. A template approach can be exactly right for a simple need. What disqualifies it is not being told which one you’re getting. Ask directly. A developer who can’t say what’s excluded from their own number hasn’t finished pricing it — they’ve finished guessing at it, same as the other two.
How to check it yourself
- Ask every quote for a line-item breakdown, not a single figure. If one won’t provide it, ask why — and treat “trust me” as an answer that costs money later.
- Ask what’s explicitly excluded: testing, documentation, deployment, post-launch support. Silence on this usually means it isn’t included.
- Ask what would make this specific quote go over budget. A specific answer (“if the payment gateway doesn’t behave the way its documentation claims”) is a good sign. A vague one (“if requirements change”) is not.
- Ask whose name the hosting, repository, and API keys will be registered under. If the answer isn’t yours from day one, that’s a cost you’re deferring, not avoiding.
- Compare the three quotes item by item, not total by total. You’re looking for what’s different, not which number is smallest.
Where this pattern comes from, so you can weigh it
Reviewing scope before work starts is a standing part of the job I do now — Senior Principal Lead Architect, 17+ years in IT, time on both sides of that table at different points in a career. That’s a lot of years spent watching the same spread appear, which is rather the point: you don’t have to spend them yourself to know what it means. Two proposals for what’s described as the same system, priced worlds apart, and the gap is never really about honesty. It’s about how much of the unwritten part each side decided to price in, versus find out about later and bill you for.
The fix isn’t finding an honest developer instead of a dishonest one. It’s removing the guessing before anyone puts a number on paper. The brief does that. Nothing else does.
What to do next
If you’re holding quotes that don’t make sense next to each other, you already have what you need to take them apart: compare what’s actually inside each number, line by line. That beats picking the middle one and hoping. And if you want an outside read on whether a scope is realistic before you commit budget to it, get a free project diagnosis. You’ll leave with a straight answer — including an honest no, if that’s the right one.
For how a custom build actually gets scoped and delivered once the brief is solid, see how a custom web application project is built.
Common questions
Why do software development quotes vary so much for the same project?
Because each developer is pricing their own guess about the parts of the brief you didn’t write down — the edge cases, the integrations, who’s covering testing and documentation. Two developers can read an identical paragraph and price two different projects, because they’re each filling the gaps differently. The variance closes considerably once the brief specifies outcomes, users, exclusions, and what happens when something goes wrong — at that point, the quotes are finally pricing the same thing.
Is a fixed-price quote safer than an hourly one for custom software?
Not automatically — each shifts a different risk onto a different party. Fixed price puts the risk of a scope overrun on the developer, which is why a careful one prices in a buffer for the unknowns before quoting. Hourly puts that risk on you, which is fine if the scope may genuinely evolve but expensive if there’s no cap and no regular check-in on hours burned. Which one actually protects you depends on how well-defined the scope already is going in — vague scope makes both arrangements risky, in different directions.
What should be included in a custom software quote besides the build itself?
Testing, documentation, help getting deployment and hosting set up, and clarity on who owns the code repository and credentials once the project ends. A quote missing these isn’t necessarily dishonest — some developers price them separately on purpose — but it is incomplete, and the missing pieces have a habit of reappearing later as change orders billed at a worse rate than if they’d been scoped from the start. Ask what’s excluded before you compare the number to anyone else’s.
Should I go with the lowest quote I received?
Not automatically. A quote that’s well below the others usually means one of three things: the edge cases haven’t been fully scoped yet and will surface later as change orders; the number quietly excludes testing or documentation; or the plan is a template or no-code approach, which may be entirely appropriate for a simple need but should be disclosed as the plan, not discovered later. None of those three automatically disqualify the low quote. What costs money is treating the smallest number as the safest one without asking what it leaves out.