Why Do App Development Quotes Vary So Much? How to Normalise Them

Send one app brief to five agencies and the quotes will not cluster. In my experience the highest number can come back several times the lowest, and the first instinct is always the same: somebody is trying it on. Almost always, nobody is. The five suppliers have read the same document and priced five different projects, and the spread is a measurement of how much your brief left open rather than of how much anyone wants to charge.

I have written these quotes and I have sat on the other side of them, being compared against four others. What follows is where the numbers actually separate, and how to get them onto one page so you are comparing the same thing.

Why do app development quotes vary, if not on rate?

Rate is the variable people reach for because it is a single number and it feels comparable. It is real — a team of senior engineers in a high-cost market and a blended team weighted toward junior developers are genuinely different prices per day — but on most briefs it is not the biggest term.

The bigger terms are how much work each supplier thinks there is, and what each of them believes they have to deliver before they can stop. Two suppliers can agree precisely on rate and still be a long way apart on total, because one of them is quoting four months and the other is quoting ten.

The five places the numbers separate

Assumed scope

Your brief says the app lets users "manage their orders". One supplier prices a list and a detail screen. Another prices a list, filters, search, a detail screen, editing, cancellation with its rules, a refund path, push notifications for status changes and an audit trail, because in their experience that is what "manage" turns into by week six.

Neither has misread you. The brief genuinely supports both. Every ambiguous verb in a brief — manage, handle, support, integrate with — is a place where quotes will separate, and the separation compounds.

The definition of done

This is the one that surprises people most. "Finished" means different things at different suppliers.

At the light end: the features work, on the tester's device, and the build is handed over. At the heavier end: automated tests, testing across a real device matrix rather than one simulator, crash reporting wired up, analytics events defined, an accessibility pass, store listings written and assets produced, submission handled, and a documented pipeline that lets the next build ship without the original developer.

That is not the same product. Expecting it to be the same price is the mistake.

Platform strategy

One app or two? A cross-platform framework does share a codebase across iOS and Android, which is a real reduction in the build line. It does not remove the platform work: two store submissions, two review processes, device testing on both, and native modules for anything the framework does not cover — background location, a specific hardware feature, a payment SDK that only ships natively.

There is also a web answer to the same question, and sometimes it is the right one. The product in the StartX case study leads visitors to apps on three separate stores, but the site itself carries the explaining and the conversion. Deciding what has to be an installed app and what can be a website is a scoping decision that moves the number more than any framework choice does.

Who carries the risk

A fixed price is not a lower price. It is a transfer of risk from you to the supplier, and a competent supplier prices that transfer. If the scope is genuinely settled, that premium can be worth paying for the certainty. If it is not settled — and on a first app it is almost never settled — you are paying a premium to fix something that is going to move anyway, and then paying again through change requests when it does.

Time and materials looks cheaper on the page precisely because the risk stayed with you. Compare a fixed-price quote against a time-and-materials estimate without accounting for that and you are comparing a price to a forecast.

Team shape and blended rates

Offshore, onshore, nearshore, blended. A blended rate hides the composition, and the composition is what you are buying. One senior engineer with domain experience and two juniors is a different proposition from five mid-level developers, and both are different from a single contractor.

What I would ask is not where the team sits but who specifically is on it, what else they are committed to during your project, and who makes the architectural decisions. A cheap blended rate with nobody senior making decisions is not cheap. It shows up later as a rebuild, which is a cost I have written about separately in rebuilding an AI-built app for production.

The exclusions matter more than the total

Read the exclusions page first and the cover page second. The exclusions are where the difference between two quotes actually lives, and they are rarely hidden — they are just at the back, in smaller type, after the number that people stop reading at.

Things I regularly see excluded, entirely reasonably, and then not noticed:

• Backend and infrastructure. An app is a client. If it holds accounts, syncs data or does anything a spreadsheet could not, there is a server-side project behind it. Some quotes include it, some assume you have it.
• Third-party costs. Push notification services, maps, SMS, email delivery, error reporting, analytics. Usually billed to you directly, and correctly excluded from a development quote — but they are still your costs.
• Store accounts and fees. Apple charges an annual fee for the Apple Developer Program and Google Play charges a one-time registration fee; check both for current pricing. More importantly, decide whose accounts these are. Your app should live in accounts you own.
• Store submission and review. Getting a build through review is a task with an unpredictable duration. Rejections happen for reasons in the App Store Review Guidelines that have nothing to do with code quality — metadata, account deletion, subscription wording. Someone has to respond to them.
• Content. Copy, translations, legal pages, the privacy policy the stores require, the screenshots and the listing text. This is real work and it is very often nobody's line item.
• Design revisions beyond a set number. Reasonable to cap. Worth knowing the cap.
• Everything after launch. Which deserves its own section.

The year after launch is not optional on mobile

A website you neglect degrades slowly. An app you neglect stops working, and on a clock you do not control.

Google Play enforces a target API level requirement that rises each year, and apps that do not meet it stop being available to new users. Apple's tooling and SDK requirements move on their own schedule. Operating system releases break things that worked. Your own dependencies get deprecated. None of this is triggered by you shipping a change; it happens whether or not you touch the app.

So an app maintenance line is not a support contract for bugs. It is the cost of the app continuing to exist in the stores. A quote that ends at launch has priced a product with a shelf life. The same question applies to web work, where I have set out what belongs in a retainer in what it costs to maintain a website per year.

How to normalise five quotes onto one page

Do not compare totals. Rebuild every quote into the same rows and see what is missing. I deliberately have not put figures in this table — fill it from the documents in front of you, because your numbers are the only honest ones here.

Then apply one rule. Where a supplier has a dash, either ask them to price that row or accept that you are paying for it elsewhere — with your own staff's time, with a second supplier, or with a change request at a rate you have not negotiated. A quote is only cheaper when it is the same quote.

Questions that expose a lowball

None of these are gotchas. They are the questions a supplier who has genuinely priced the work answers in specifics, and a supplier who has priced a hope answers with reassurance.

1. "What is excluded?" Ask for it as a written list, not a conversation. The length and precision of the answer tells you how carefully the quote was built.
2. "What are you least confident about in this estimate?" Integrations and data migration are the honest answers. "Nothing" is the answer to worry about.
3. "What happens if Apple or Google rejects the build?" You want to hear a process, not a promise that it will not happen.
4. "Who owns the store accounts, the code repository and the third-party services?" One sentence, in the contract.
5. "How do change requests work, and what is the smallest one you will take?" Suppliers who underquote often make it back here. Suppliers who quoted properly usually have a simple answer.
6. "Which named people are on this, and what else are they on?" Availability is a real constraint and vague answers about "our team" usually mean it has not been allocated.
7. "What does month thirteen look like?" The single most useful question on the list, because it forces the supplier to describe a world after the invoice.

The rule I would use

Shortlist on the exclusions, not the total. Once every quote covers the same rows, the remaining spread is genuinely about team, experience and risk appetite, and at that point the cheapest quote is a legitimate choice. Before that, it is just the quote that left the most out.

And if every supplier's number is well above your budget, the answer is not to find a sixth supplier. It is to cut scope deliberately — pick the one workflow that has to exist, ship that, and let real usage tell you what the second version needs. That is nearly always a better use of the money than buying a cheaper version of everything, and it is the same argument I make about what custom software actually costs.

If it would help to have a second set of eyes on the quotes you have, that is the thinking we bring to app development and the backend work that usually sits behind it.