How we estimate software projects (and why the number is a range)

Every software buyer has lived this: three vendors, three quotes, and the numbers span a 4× range. The instinct is to assume someone is lying. Usually nobody is; they're just estimating different projects, because the brief left most of the project undefined.

An estimate is a prediction about a system that doesn't exist yet, built from a description that's incomplete by nature. The honest response isn't false precision; it's making the uncertainty visible and then shrinking it deliberately.

The anatomy of our estimates

We quote ranges with named assumptions. '€28-36k assuming: single admin role, no legacy data migration, payment provider is Stripe, content provided by you.' Each assumption is a switch: flip one and the number moves, and you can see which switch moved it.

The width of the range is information. A tight range means we've built this shape before; a wide one means discovery should come first. When a range embarrasses us into 'we honestly don't know yet', that's what a one-to-two-week paid discovery is for: it converts the widest unknowns into scoped facts for a fraction of the build cost.

Fixed-price quotes come after that convergence, not before it. A vendor who gives you certainty on day one has either priced in a large fear premium, or is planning to renegotiate through change orders once you're committed. Both cost you more than honesty would have.

Where estimates actually go wrong

In our experience the overruns rarely come from engineering being slow. They come from three places: integrations with systems nobody fully understood ('it has an API' is not documentation), workflows that turned out to have exceptions the happy-path brief never mentioned, and decisions that waited weeks for a stakeholder while the team built around the gap.

So those are exactly the things we probe before quoting: we ask to see the API docs, we ask 'what's the weirdest order you've ever handled', and we agree a decision-turnaround rhythm as part of the contract. Estimation isn't arithmetic; it's risk archaeology.

What you can do as a buyer

Ask every vendor for their assumptions in writing. Ask what would make the number go up, and by how much. Ask which parts of the estimate they're least sure about. A vendor who can't answer that hasn't thought about your project, whatever the proposal's page count says.

And treat the cheapest quote with the same scrutiny as the most expensive one. Someone has to pay for an underestimate, and it's rarely the vendor.