You've asked three developers to build the same thing. One says €8,000 and six weeks. One says €25,000 and four months. One says "give me a couple of days, I'll knock it out for €2,000."
You can't read the code. You can't judge the architecture. So you do the only thing you can: you compare the numbers, and the cheapest confident one wins.
That's how buyers get burned. Not because they made a foolish choice, but because the one signal they can read — the price — is the one signal that's easiest to fake.
The good news is that you don't need to read code to read a quote. A quote is a document written by a human being making judgments about uncertainty, and the way they handle that uncertainty tells you almost everything about how the project will go. You just have to know what to look at.
Why the Cheapest Quote Is Usually the Most Expensive
There's a reason the lowball number feels safe: it removes the scariest variable, cost, and it does it decisively. No hedging, no ranges, no "it depends." Just a small, confident figure. Decisive feels competent.
But in software, a small confident number for a non-trivial job is almost never competence. It's one of two things: the person doesn't yet understand what the work involves, or they understand it fine and they're pricing to win the deal, planning to make it back on change orders once you've already committed.
Both end in the same place. The naive quote runs out of money halfway, because the work was always going to cost more and reality doesn't care what was promised. The strategic lowball invoices you for everything the original number quietly excluded. Either way, the €8,000 project becomes a €20,000 project — except now it's late, half-built, and you've lost the leverage you had before you signed.
The expensive part of cheap software is never the invoice. It's what you build on top of it. A cheap quote buys you a system that works in the demo and breaks the first time a real customer does something the developer didn't picture. You find out in production, with your name on it. Rebuilding it costs more than doing it right would have — plus everything you lost while it was broken.
I'll say the uncomfortable version plainly: when you pick the cheapest quote for real business software, you're usually not saving money. You're deferring the real cost to a moment when it's more expensive and less recoverable.
Why "Two Weeks" Almost Always Means Six
This isn't developers lying to you. It's structural, and understanding why makes you a much harder buyer to fool.
When someone quotes a feature quickly, they're picturing the happy path — the version where everything works. Customer clicks the button, the data's valid, the payment goes through, the page loads. That mental movie runs in a few seconds and feels like the whole job.
It's maybe a third of the job.
Everything the demo doesn't show sits underneath: what happens when the data's wrong, when the payment provider times out, when the customer double-clicks and you're charged twice, what the screen looks like while it's loading and when it's empty and when it errors. Then someone has to test it, find the problems, fix them, and re-test the things the fix broke. None of that is in the two-week picture, and none of it is optional. A feature that only handles the happy path isn't 90% done — it's a prototype that happens to demo well.
There's a second trap hiding in every fast number. A developer estimates effort — "that's about five days of work" — and it gets heard as duration — done in a week. Those aren't the same thing. Five days of actual focused work don't fit into a five-day week, because a working day isn't eight hours of that one task. It's meetings, other people's questions, the context-switching, the admin. Five days of effort is closer to two weeks on the calendar before anything goes wrong.
So when you hear a fast, small number, the honest translation is: that's the best case, for the part they can see, if nothing surprises them. Something always surprises them. That's not pessimism — it's the base rate. If you want the longer engineering version of why this happens, I wrote it up in why "two weeks" always means six.
The Questions That Expose a Padded or Naive Estimate
You don't need technical vocabulary to test a quote. You need questions that force the person to reveal how they think about uncertainty. Ask these, and listen to the shape of the answer more than the content.
"What's your estimate, and what's the range?" A single number is a red flag. Not because ranges are more honest as a style, but because uncertainty is real and a single number pretends it isn't. A good answer sounds like: "Three weeks if the payment integration behaves the way its docs claim, five if it fights us the way these usually do, and my honest expectation is around four." That person has thought about what could go wrong. The one who insists on a single confident number either hasn't, or is hiding it.
"What's not included in this price?" The answer tells you whether they've thought past the happy path. "Nothing, it's all included" from a cheap quote means they haven't mapped the work. A real answer names things: data migration, third-party costs, revisions after your feedback, testing, the stuff that's genuinely out of scope. A quote that can't tell you what it excludes hasn't defined what it includes.
"What are you assuming to hit this number?" Every estimate rests on assumptions. "Three weeks, assuming your existing data is clean and the payment provider's system works as documented" is a real estimate — because when an assumption breaks, you get a named reason instead of an unexplained overrun. Someone who can't state their assumptions is giving you a number that stands on nothing.
"What would make this take twice as long?" This one's diagnostic. The person who says "nothing, it's straightforward" is telling you they haven't found the risks yet — which means you'll find them together, later, at your expense. The person who can immediately name two or three things that could blow up the timeline has actually looked at the problem.
The pattern underneath all four: you're not testing their coding. You're testing whether they've thought about what they don't know. A confident answer to every question is the worrying one. Some honest hesitation, some "it depends, here's what it depends on," is the sound of someone who's done this before.
When a High Quote Is Not Justified
Filtering out lowballs is only half the skill. The other half is not overpaying, because expensive isn't automatically honest either. Some high quotes are padding, over-engineering, or someone charging you for complexity you don't need yet.
Here's how to tell the difference. A justified high number comes with a justified high scope — it's expensive because it's solving a genuinely hard problem, handling real edge cases, or building something that has to survive scale you actually have. The seller can point at what the money buys and it maps to something you recognize as real.
An unjustified high number is expensive because the seller is building for a future you don't have yet. Watch for these:
- They're pricing for scale you don't need. You have zero users and they're quoting a system that handles a million. Building for load you don't have is real work you're paying for and won't use for years, if ever.
- They're gold-plating the parts that don't matter. A beautiful admin dashboard with analytics before you have anyone to analyse. Elaborate user roles and permissions before you have a second type of user. These sound responsible and are, at your stage, expensive guesses. I listed the specific ones that reliably kill early products in features that kill MVPs.
- They can't explain the number in your language. If a seller can't tell you why it costs what it costs without retreating into jargon, one of two things is true: they don't understand it well enough to explain, or they'd rather you didn't understand it well enough to question it. Neither is worth your money.
The honest expensive quote and the honest cheap quote have the same tell: the person can walk you through what the money buys, in plain words, and it holds up. The dishonest versions — padded high or naive low — both fall apart the moment you ask them to explain.
The One Thing to Do Before You Sign
If you take one action from this, make it this: ask each bidder to separate the estimate from the commitment.
The estimate is their honest technical guess at the effort. The commitment is the date and price they'll actually stand behind. These should be different, and the gap between them — the buffer for the things nobody can see yet — should be visible, not hidden.
A seller who says "my estimate is six weeks, but given what we don't yet know about your existing data, I wouldn't commit to a customer-facing date tighter than nine" is doing the honest thing out loud. A seller who gives you one number that's secretly the estimate promised as a commitment with no buffer is setting up the overrun you'll live through in month three.
And here's the filter, stated plainly, because it cuts both ways. If you punish the honest sellers — the ones who give you ranges, name their risks, and refuse to promise a comforting single number — and reward the confident lowballer, you are training your suppliers to lie to you. You will get exactly the quotes you selected for: small, confident, and wrong. The seller who won't compress an honest range into the number you want to hear is being useful, not evasive. That's the one to keep.
You can't read the code. You don't have to. You can read whether the person in front of you is comfortable being honest about what they don't know — and in software, that's the thing that predicts whether the project ships.
If you're staring at two quotes with a gap you can't explain, don't guess. Let's read the proposal together — I'll tell you which number is real and which one is a problem you haven't met yet.
