Why Two Quotes for the Same App Can Be Worlds Apart

You send the same description to three developers. Three quotes come back: the first is a few thousand euros, the second is three times that, the third has an extra zero.

The instinctive reaction is to think the first is a bargain and the third is trying to take advantage. Usually it's neither. In most cases, the three developers have simply quoted three different projects.

If you want a general idea of price ranges, I covered that in How Much Does It Cost to Build an App in 2026?. Here we look at why the differences exist, and how to compare quotes sensibly.

“A booking app” sounds like a clear description. It isn't.

It can be a ready-made template with your logo, where customers pick a time slot. Or a platform with online payment, a management panel for staff, notifications, cancellation handling, statistics and an app published on the stores. Both are called “a booking app”. The second can cost ten times the first, and for good reasons.

When the description leaves room for interpretation, each developer fills it in with their own experience, their previous projects, or what they think you want to hear.

What sits behind the screens. What the customer sees is often the smallest part. The management panel, the server, the database, integrations with other systems: if a quote doesn't mention them, ask whether they're included.

Analysis and design. Some developers spend time understanding the problem before writing code; others dive straight in. The first approach costs more at the start. The second usually costs more at the end, when you find out what was missing.

Testing and publishing. Testing the software on different devices, publishing it on the stores, handling Apple and Google reviews: these are real hours of work, and not everyone accounts for them.

Custom or adapted. A customised template costs less than software designed from scratch. That's not a flaw: if the template meets your needs, it's the right choice. What matters is knowing which of the two you're buying.

Who actually works on the project. A freelancer, an agency with an in-house team, an agency that subcontracts development elsewhere. The cost changes, and so does who answers when something goes wrong.

What happens after launch. Bug warranty, updates, support. Some quotes include it, others treat it as a separate service.

Before comparing the figures, put the quotes side by side and ask each one the same questions.

I've written a separate article on the second-to-last point: Source Code, Domain and Accounts: What Must Stay Yours When You Commission Software.

I want to be honest about this too. Sometimes the lowest quote is the right one: because the developer is proposing a template that genuinely covers your needs, or an existing solution to configure rather than software to build.

The problem isn't a low price. It's a low price that doesn't tell you what it leaves out.

More than the figure, look at how it was reached. A developer who sends you a detailed quote without asking you a single question is quoting a project they imagined. It might match yours. More often it doesn't.

The questions — who will use the software, what it must do on day one, what can wait, which systems it needs to talk to — aren't a waste of time. They are the quote.

The best approach is to send everyone the same description, a little more precise than would come naturally. You don't need a technical document: clear answers to a few questions are enough. What problem needs solving. Who will use the software, and on which device. What it absolutely must do from day one, and what can come later. Which tools you already use that it needs to connect to. When you need it by.

And, if you can, give a rough budget. It isn't showing your hand: it lets whoever replies propose the best solution for that figure, instead of guessing.