Three suppliers heard the same description of your app. One came back at AED 15,000, one at AED 60,000, and one at AED 150,000. The instinct is to assume somebody is trying it on.
Usually nobody is. What has happened is that three suppliers filled in the gaps in your description three different ways, and the gaps were where the money was. The cheapest quoted the smallest honest interpretation. The most expensive quoted the most complete one. Neither of them told you which, because neither of them knew you were comparing.
This article is about the variance and how to close it. Our app development cost guide covers what the components actually cost, and our guide to reading a software proposal covers the clauses. This one is about the number.
The costs nobody can avoid, which give you a floor
Apple charges 99 US dollars a year for the Developer Program and Google charges 25 US dollars once [1][2]. Those are the only two numbers in any quote that are not a judgement call, which makes them a useful floor.
Neither figure is published in dirhams, so treat any AED conversion in a quote as approximate arithmetic rather than a published price.
Then there is the work around them: store account setup, signing certificates, push notification provisioning. Our own cost guide puts that at a fixed AED 1,500 to 3,000 in year one, which is a useful sanity check against a quote that appears to include store publication for nothing.
Both stores also require compliance disclosures before you can publish. Apple requires App Privacy details covering what data you collect and why [5], and Google requires the Data safety form making equivalent declarations [6]. Google publishes core app quality expectations as well [7]. None of that is optional and all of it takes somebody's time.
And then there is the gate nobody quotes. Google requires a new personal developer account to run a closed test with a minimum number of opted-in testers for fourteen continuous days before the production track becomes available [3]. As checked in August 2026 that minimum was twelve testers, and the requirement has changed before, having previously been higher [3]. Treat the number as current rather than permanent.
That last item is the single most useful question in a supplier conversation, because it has nothing to do with price. Ask how Google's fourteen-day testing window for new personal developer accounts affects the launch date. A supplier who has published an app recently will answer immediately. One who has not will ask what you mean.
Review time is worth calibrating too. Apple states that on average ninety per cent of submissions are reviewed in less than twenty-four hours [4], which is a platform-wide average rather than a commitment for your app. Our app rejection guide covers what actually causes submissions to fail.
The four questions that explain most of the spread
Almost all of a tenfold gap resolves into four decisions that nobody wrote down.
Is design included? A quote that assumes you supply designs, or that default platform components arranged sensibly is enough, is a genuinely different product from one including research, screen design and a design system. Both are legitimate. They are not the same purchase.
Is there a backend? An app storing data on the phone is a fraction of the work of one with a server, a database, user accounts and an admin interface your team can use. If you need to see your own data, you need the second thing. Two suppliers can both say "your app" and mean either.
Is testing included? Our QA guide puts a focused test pass on an existing build from around AED 4,000, which tells you roughly what is being omitted when a quote has no testing line.
Is anything included after launch? Usually a warranty period at most. Our maintenance guide starts from around AED 500 a month for a simple app, or fifteen to twenty-five per cent of build cost per year, so a quote silent on support is understating year one.
Ask those four, in writing, of every supplier. The replies typically close most of the gap before anyone renegotiates anything.
Where a cheap quote makes its money back
Often nowhere, and the supplier simply quoted a smaller product accurately. Where it does happen, the mechanism is change requests.
Where it does happen, the mechanism is change requests. Anything not written down becomes a variation, and variations get priced when you are no longer shopping around. That is not a trick. It is the predictable arithmetic of a thin scope meeting a real business.
So the defence is not suspicion, it is specificity. A written scope with named screens and explicit exclusions removes the mechanism entirely, and it does so for every supplier at once.
Where an expensive quote earns it, and where it does not
It earns it on: real design work rather than arranged defaults, a data model that survives your business changing its mind, test coverage, accessibility, a security review, and a named person accountable after launch. Those cost money because they are work.
It does not earn it on: headcount for its own sake, or a process that produces documents rather than software. A large team on a small product costs more and moves slower. A discovery phase that delivers a slide deck rather than a decision is a cost with no output.
Two questions separate them. What will each named role actually do on my project? And what artefact does each phase produce that I keep?
Our own numbers are not perfectly consistent either
It would be a poor article that told you to scrutinise other people's pricing while presenting ours as immaculate.
AED 15,000 appears across our own guides as a focused first version of custom software, as an app design engagement, and as a native single-platform starting point. Those are genuinely different scopes at a similar price. The reason is that each guide was written for a different buyer and each is internally defensible, but read side by side they demonstrate the exact ambiguity this article is about: a number means nothing without the scope attached.
We are working through that inconsistency across our own cost pages. In the meantime, treat any figure of ours the same way you should treat anybody's: as an entry point attached to a specific scope, not a price for your project.
A pattern we see. A business picks the middle quote, on the reasonable-sounding theory that it splits the difference. But the three quotes were not three prices for one product, so the middle number is not a compromise. It is the option whose scope nobody examined. Four months later the missing backend or the absent testing shows up as a variation, and the middle quote finishes above the highest one.
The line items to insist on
Ask for the price broken into these, and the comparison problem largely solves itself. A supplier who will not break it down is telling you the breakdown would be awkward.
| Line item | What to confirm |
|---|---|
| Discovery and specification | Does it produce a document you keep, or a conversation |
| Design | Screen designs, or defaults arranged sensibly, and how many revision rounds |
| Frontend build | Which platforms, and how many screens by name |
| Backend and data | Is there a server and a database, and can your team see the data |
| Integrations | Each third-party connection named and priced separately |
| Testing | Who tests, against what, and what happens when they find something |
| Store submission | Listings, screenshots, privacy disclosures, and handling a rejection |
| Post-launch support | How long, what it covers, and what response time |
| Store fees and setup | Shown separately rather than absorbed or omitted |
The two rows people skip are the last two, and they are the ones that make a launch date real. A build is not a launch, and a launch is not a supported product.
One more thing worth asking for in the same breath: the assumptions. Every quote rests on assumptions about what you will provide, how quickly you will decide, and who has authority to approve. A supplier who writes those down is protecting both of you. A supplier who does not will raise them later, when they have become your fault.
How to make three quotes comparable
Send all three suppliers the same written scope and ask them to price it in the same shape. It takes an afternoon and it resolves most of the spread.
Send all three suppliers the same written scope, and ask each to price it in the same shape:
- A named list of screens or features, so "your app" means one specific thing
- Explicit inclusions and exclusions, with the exclusions given equal weight
- Separate lines for design, build, testing, store submission, and post-launch support
- Stated assumptions about what you will provide, such as content, brand assets or a decision-maker
- The store fees and setup shown separately, so they are not silently absorbed or silently omitted
Some suppliers will push back on the format. How they push back is informative. A supplier who says the exclusions list will be long, and then writes it, is being straight with you. One who says it is unnecessary at this stage is telling you when you will find out.
Three quotes, one worked example
It helps to see how the arithmetic actually resolves, using a simple case: a business wants an app where customers book a service and staff see the bookings.
The low quote prices a single-platform app with screens arranged from default components, no separate design phase, bookings stored against a hosted backend the supplier already uses for other clients, no test phase, and a handover at working-build stage. That is a real product. It is also a product where your staff view bookings in somebody else's admin tool, you cannot change the booking flow without a variation, and the store submission is yours to learn.
The middle quote prices designed screens, a backend you own with an admin area for your team, a test pass before submission, and thirty days of defect fixing after launch. Same described product, four more line items.
The high quote adds user research before design, both platforms rather than one, accessibility, a security review, and a support arrangement with a response time. Still the same described product.
Nobody in that example is dishonest. The buyer described a booking app and three suppliers made three reasonable guesses about what that meant. The whole spread is scope, and it becomes visible the moment somebody writes the line items down.
The useful realisation is that the buyer's job is not to work out which supplier is right. It is to decide which of those three products they actually want, and then get all three to price it.
If you cannot write the scope yourself
Then buy it, as a small separate piece of work, rather than asking three suppliers to invent one for free.
A short paid discovery producing a written specification you own starts from around AED 4,000 with us. Ask us to structure it so you can take the document to other suppliers, including instead of us, and hold us to that. These are our own figures rather than a market survey. Final pricing depends on how much of the product needs defining.
That last point is worth being explicit about, because it sounds like a strange thing for a supplier to offer. The alternative is competing on who guesses lowest against an undefined scope, which reliably produces bad projects and unhappy clients on both sides. We would rather lose a fair comparison than win a misunderstanding, because the second one becomes our problem about four months in.
What changes after you sign
Four things change your total after signature: variations, assumptions turning into charges, how much of the money is left at the end, and what year one costs rather than what the build costs.
Variations. Every change to an agreed scope has a price, and that price is set without competition. This is not a failure of the supplier, it is the structure of the arrangement. The defence is deciding as much as possible before signing and accepting that some variations are your own change of mind rather than anyone's omission.
Assumptions turning into charges. A quote that assumed you would supply content, brand assets, or a decision within two days will re-price when those do not arrive. Read the assumptions and be honest about which ones you will actually meet.
The last payment. Whatever remains at handover is the only leverage you retain, so it should be meaningful and tied to something verifiable rather than to a date. A project where the final payment is small or already made is a project where the final ten per cent of quality is optional.
Year one, not build cost. The number to compare across suppliers is the first twelve months: build, store fees and setup, testing, submission, and support. A quote that wins on build cost and loses on year one is the more expensive quote, and it is common because build cost is what buyers ask about.
None of that argues for choosing the highest quote. It argues for comparing the right number.
What to actually do this week
- Ask every supplier, in writing, what is excluded from their price
- Ask the four questions: design, backend, testing, post-launch support
- Ask how Google's mandatory fourteen-day testing window, which applies to new personal developer accounts, affects the launch date
- Confirm whether store fees and setup are inside or outside the number
- If the scope is not written down, get it written down before choosing anybody
- Compare the answers, not the numbers
The single most useful sentence you can send is the shortest. What is excluded from this price? Most of the spread you are staring at will resolve itself in the replies.
If you would like a written specification you can take to three suppliers, contact us.
A note on our own incentive
You are reading pricing advice from a company that sells the thing being priced, so treat the framing with the scepticism it deserves.
Our interest here is specific and worth stating. A buyer choosing on an undefined scope is choosing on optimism, and optimism reliably favours whoever wrote the least, which is a poor way for anybody to win work. A buyer with a written specification either picks us for reasons we can defend or picks someone else for reasons that are probably right. Both of those are better outcomes than winning a project that was misunderstood at signature.
So the advice in this article is genuinely in our interest, which is the only kind of advice from a supplier you should trust without checking.
References
[1] Apple, Apple Developer Program enrolment and fees. developer.apple.com
[2] Google Play Console Help, Registration fee. support.google.com
[3] Google Play Console Help, Testing requirements for new personal developer accounts. support.google.com
[4] Apple, App Review. developer.apple.com
[5] Apple, App Privacy Details. developer.apple.com
[6] Google Play Console Help, Data safety. support.google.com
[7] Google Play, Core app quality. developer.android.com
