“How much for an app?” is the hardest question in this trade to answer. App development cost depends first on which of three different products the person asking has in mind, and those three share little more than an icon on a home screen.
So two quotes that differ by multiples may both be fair, each priced for a different product. The first decision is which of the three you are buying; only then does it make sense to ask what moves the number inside it.
Three different things called an app
A wrapper around your website. The app opens your site inside a frame and adds an icon. As Apple’s App Review page put it on 23 October 2026, “Websites served in an iOS app, web content that is not formatted for iOS, and limited web interactions do not make a quality app.” Google Play Console Help, on the same date, states the rule for its store as “We do not allow apps that only have limited functionality and content.”
If your site already works on a phone, an icon adds little that your customers do not have already. The money is better kept for one of the other two.
A product with one journey. Ordering, booking or a service people pay for: accounts, the flow itself, payments, notifications, all of it working on iPhone and Android. With a small team, this is eight weeks of work.
A platform. Two sides, money held between them, disputes, and an admin side where someone settles them. Our own marketplace took four months, including the backend, the money handling and the admin side.
Check which of the three each quote is for. Quotes for mobile app development cost can sit far apart simply because one prices a wrapper and another a platform, and neither figure tells you anything about the product in the middle.
The second product is the one we build as a first release, set out on our mobile app development page.
What the money buys: an app development cost breakdown by product
A quote is easier to read once each part of it is matched to the product that needs it. The parts below name the products they belong to; a wrapper needs almost none of them.
- The app itself on iPhone and Android. For the second product and the platform it is built from one codebase, the single body of code that both versions are made from. A wrapper has little code of its own beyond the frame around your site.
- The server side. This is the part that runs away from the phone and holds accounts, orders and data. The second product and the platform need one, either built new or connected to one the business already runs.
- Payments and their failure states. A card declined, a refund, a payment that half-succeeded. The second product has them when people pay inside the app; the platform has them by definition, since it holds money between two sides.
- Notifications and permissions. The messages the app sends and the access it asks for on the phone, such as the camera or location, for the second product and the platform alike.
- Automated tests. In our price they are not on top: integration tests that drive the real app on a real device, in your pipeline, the automated steps that build and check each version.
- The submission to both stores. Both store listings go in with the account and the signing keys in your name, so the listing stays under your control after the work ends.
- The second side and the admin screen. For a platform only: the screens for the other audience, and an admin side where someone settles disputes and moves money.
On one codebase, the second store is a small line in the cross-platform app development cost of a first release, not a doubling of it.
The list says which parts each product needs. How large each part grows inside a given product is set by four things.
Four things that move the number
These four questions change the figure inside any of the three products more than the length of a feature list does. Each can be answered from a plan before anyone writes code.
Whether money moves inside the app. Payments bring failure states, refunds and the awkward middle where a payment half-succeeded. It is not a screen; it is a category of work, and each of those states needs a screen, a message and a test of its own.
Whether there is a server, and whose it is. An app is a client for something: it shows and sends data that live elsewhere. If that something exists and has a decent API, a documented way for other programs to talk to it, the app is most of the work. If it does not, you are buying two products.
Offline and poor networks. For example, an owner might ask for an app that “should work in the warehouse basement”. That is one sentence in a request and a whole layer of work, because the app has to keep what people do without a signal and settle it with the server later. Worth every hour when your users are actually there, and worth cutting when they are not.
How many sides use it. One audience is a product. Two audiences with different tasks, permissions and screens are closer to two products that must agree with each other. A buyer and a seller, or a customer and a courier, each need their own app or their own half of one.
Why the second platform is not a second bill
People ask about iOS app development cost and Android app development cost separately, as if each were a bill of its own. On one shared codebase the second platform is a fraction of the first, not a second bill: the screens, the flow and the connection to the server side are written once.
Native means two codebases, one written for each platform, and close to a second project once the first is done. That is one reason two quotes for the same product can differ so much: one may price a shared codebase and the other two native apps.
Which way suits your product is the question of native or cross platform, and it belongs before the quotes are compared, because it decides what each of them is for.
When a quote names a figure per platform, ask whether the two figures come from one codebase or two. The answer can explain much of the gap between that quote and the next.
A typical figure, a simple app and a prototype each need a product named first
The average cost to build an app is a figure taken across all three products at once: wrappers pull it down, platforms pull it up, and the result describes none of them.
For that reason no average and no range appears here, from price guides or from anywhere else; a figure that mixes three different products cannot tell you what yours will need.
The cost to build a simple app runs into the same problem. “Simple” only means something once it names the one thing the app must do and what it leaves out: payments, offline use, a second side.
For example, an app where a customer books a slot and gets a reminder is simple until it also takes a deposit. At that point the payments line from the breakdown above joins it, with every failure state that comes with money.
The app prototype cost is the price of an answer rather than a product. A prototype pays for finding out what the first release must contain before code is written, and it ends with a decision, not with an app in a store.
What is not worth paying extra for
Some lines raise a quote without making the product better at the one thing it is for.
- A design system before the product has met users. A design system is a full library of reusable screen parts and the rules for using them. It pays off once there are users and later releases to keep consistent, and our first release leaves it out.
- Animations that demo well in a pitch. They look good in a meeting and do little for someone trying to finish a task on a small screen with one thumb. They can wait until the product has earned them.
- A second platform your customers do not use. For example, if your own analytics showed nearly all of your customers on one platform, the second could wait; check the figures before deciding, not after.
A small line is still a line, and each of these three is easier to add later than to justify now.
The year after launch is a separate budget from the build, with its own lines, and the reasoning on app maintenance cost is the place to weigh it alongside the quote for the first release.
A number you can hold
One journey working end to end on iOS and Android, tested and submitted to both stores with the accounts in your name, is the first release we build in eight weeks, from $19,000.
That figure is for the second of the three products. A platform runs further, as the four months of our own marketplace show.
Paid by stage, and no stage grows unless the scope changes; a change is quoted before the work starts, and you can stop after any stage.
Set against that scope, a quote that is meaningfully cheaper usually means one platform, no tests or no server side. One that is meaningfully dearer usually means more than one journey, which may be right, but it should be a decision you made rather than a surprise you received.
Read that way, two quotes that differ by multiples can stop disagreeing: they were priced for different products.
What the first release holds, and what it leaves out, is set out on our mobile app development page.