Development quotes: why such different prices?

A development quote isn't compared, it's interpreted

Three providers, the same need, and three proposals that think they're talking about the same project, but where some serious differences emerge. One understood a showcase site, another a platform with a client area.

Prices can range from one to five times as much without anything in the documents explaining the gap. The cheapest is neither the most effective nor the best value for money: it's often the one that understood the least, or listened least to your real need.

What makes quotes comparable is putting them back on the same grid: scope covered, unstated assumptions, what's missing, what will be billed extra. The gap becomes readable as soon as you dig a little.

Deciding with nobody to judge and no technical knowledge means deciding on trust

In most SMEs, nobody has the expertise to say whether an architecture is reasonable or a timeline realistic. The skills gap actually comes before money: 42% of Swiss companies cite the shortage of digital skills as an obstacle, against 28% for lack of financial means, according to a Strand Partners survey for AWS of 1,000 business leaders conducted in 2026.

You end up choosing the provider you find likeable, or the one who presented best. It's not incompetence, it's an information asymmetry, and you pay for it later. The most important way to counter it is to take up the provider's references. Don't hesitate to ask for the contact details of companies for whom they've carried out similar projects. Don't be afraid: it's your right.

Nobody is paid to tell you not to build anything

When you ask someone who sells development whether development is needed, the answer is almost always yes. Unfortunately, most companies will always say yes to everything, or push one solution rather than another.

It's up to you to challenge: does the provider's proposal really meet your need, and is it the best way to meet it in terms of effectiveness and value for money?

The money doesn't go into what you build, it goes into what you maintain

Most of an IT budget goes into keeping what already exists running, and a large share of developers' time is spent working around choices made years ago.

That's why a simple request ends up at a price that seems absurd. Technical debt is too often underestimated. And it means that a decision about what already exists often pays off more than a new project. Many "new" projects actually turn out to be poorly identified problems with what already exists.

• What holds up, and for how long
• What is at end of life
• What really belongs to you: code, hosting, access
• What really costs, on a recurring basis and over the long term

In practice

The pragmatic conclusion of all this:

1. don't compare a quote, interpret it;
2. ask for references;
3. challenge a proposal;
4. think long term and look far ahead.