Ask three firms to quote the same project and you can receive three numbers that differ by a factor of five. This is not usually dishonesty. It is that "build me an app" does not describe a fixed amount of work, and each firm has quietly assumed a different version of what you asked for.
What actually drives the price
Integrations, not screens
Clients tend to estimate by counting screens. Screens are the cheap part. The expensive part is everything the product must talk to — payment gateways, banks, telecom aggregators, delivery partners, an existing database. Each one brings its own documentation, its own test environment, its own failure modes and its own support queue. A ten-screen app with four integrations costs considerably more than a forty-screen app with none.
Whether money is involved
Software that moves money needs work that software displaying information does not: idempotent requests, reversal paths, double-entry balances, audit trails and daily reconciliation. That is real engineering time, and skipping it does not save money. It defers the cost to the first month in production, at a worse exchange rate.
How much is genuinely undecided
A project where the business rules are settled is a construction job. A project where they will be discovered along the way is a research job. Both are legitimate, but they cannot be priced the same, and a fixed price on an undecided scope is a fiction that ends in an argument.
Who carries the risk after launch
A quote that ends at handover is cheaper than one that includes support, because it is a smaller commitment. Compare like with like — and be sceptical of any proposal where nobody is responsible once it is live.
Why you get vague answers
Partly because a firm quoting without understanding your business is guessing, and a confident guess is worse than an honest range. Partly, less charitably, because a low headline number wins the meeting and the difference is recovered later through change requests.
The way out is to pay for a short scoping exercise before committing to a build. A week of proper analysis produces a written scope, an integration list, the risks, and a fixed price you can hold someone to. It costs a fraction of the project and it is useful even if you then take it to a different firm.
How to compare proposals
Put the headline number aside briefly and ask each firm four questions. What integrations have you assumed? What happens when one of them fails mid-transaction? Who owns the source code at the end? And what happens in the first month after launch?
The answers will tell you more about the real cost than the quote does. A number that looks high next to a vague proposal is often the only one describing the entire job.