"How much does an app cost?" is the question we get most, and the honest answer, "it depends", is the one people like least. So here is what it depends on. Not a price list, because any number quoted without a scope is a guess dressed up as a fact, but the specific decisions that make one app cost three times as much as another that looks similar in a screenshot.
If you read this before your first call with any studio, you will get a far more accurate quote, and you will be able to tell which parts of that quote you can change.
1. Whether users have accounts
This is the single biggest switch. An app with no accounts can often keep everything on the phone: no server, no database, no password resets, no privacy questions about data on someone else's machine. The moment users sign in, you need a backend, a way to recover accounts, a way to delete them (both stores require it), and a privacy policy that describes all of it accurately.
Accounts are often necessary. They are not always necessary for the first version. A surprising number of apps could launch with on-device data and add sign-in once people have a reason to want their data on a second device.
2. Whether anything happens in real time
Chat, live multiplayer, shared lists that update on everyone's screen, live location. Anything where two people see the same thing change at the same moment needs a server that holds the truth and pushes changes out, plus careful handling of the cases where a phone goes into a tunnel halfway through. It is very doable. It is also a different category of work from screens that load data and display it.
3. How many places it has to run
iPhone only, iPhone and Android, or iPhone, Android and the web. A shared codebase keeps the second platform from doubling the cost, but it does not make it free: each platform still needs its own testing, its own store listing, its own review and its own handful of platform-specific fixes. Tablets, watches and widgets each add their own layer.
4. What it has to talk to
Payments, an existing booking system, a CRM, a warehouse, a government API, a hardware device over Bluetooth. Every integration adds work in proportion to how good the other side's documentation is, which you usually cannot know until someone tries. When a quote has a large contingency next to an integration, that is the reason. A well-documented payment provider is predictable. An internal system with no API documentation and one person who understands it is not.
5. Who runs it behind the scenes
Someone has to add products, approve users, answer support requests, change prices or publish content. Every one of those jobs needs either a tool or a developer. A custom admin panel can be as large as the app itself. For a first version, a spreadsheet, a headless CMS or the database's own dashboard is often enough, and it is one of the easiest places to save money without users ever noticing.
6. How custom the design is
An app built from well-made platform components, styled with your brand, costs much less than one with custom animation, illustration and bespoke interaction on every screen. Both can be excellent. The second is worth it when the feel of the product is the product: games, consumer apps competing on delight, anything where people choose you over a free alternative because yours is nicer to use.
7. How many unknowns are left when work starts
This is the hidden multiplier. A project with a clear scope, finished decisions and a tested prototype can be priced tightly. A project where half the screens are "we will figure it out" has to carry that uncertainty somewhere, either in a higher fixed price or in an hourly bill that keeps growing. Paying for a short design phase before the build is the cheapest way to turn unknowns into decisions.
What matters less than people think
- The number of screens. Ten simple screens can cost less than one screen with a complicated live map. Count behaviours, not screens.
- The framework. A competent team in React Native, Flutter or native code will land in a similar range for most apps. The choice matters for other reasons.
- Small cosmetic changes during the build. Moving a button is cheap. Changing what a button does, after the logic behind it is built, is not.
The part that is not in the build price
A finished app keeps costing money: the Apple Developer Program membership every year, the one-time Google Play registration, hosting that grows with usage, third-party services, and the steady work of keeping up with new iOS and Android releases. None of it is large compared with the build, but a plan that leaves it out will surprise you in month three.
When you ask a studio for a quote, ask for this part too. If the answer is vague, the app will probably be looked after the same way.
How we turn this into a number
We do not quote from a first email. After a thirty-minute call we write a scope that answers the seven questions above for your app, and put one fixed price on it. If a decision is still open, the scope says so and gives the price both ways. That document is useful even if you build with someone else, which is rather the point of writing it properly.