What does it actually cost to build an app?

What you are actually paying for

An app is not priced by screen count, though that is how it often gets quoted. You are paying for decisions and edge cases. A screen that lists ten items is an afternoon. The same screen with search, filters, pagination, an offline state, an empty state, and a permission rule about who sees what is a week.

This is why two developers can quote wildly different numbers for the same brief. One is pricing the happy path. The other has noticed the parts that are not in the brief yet.

The five things that move the number most

Whether it needs a backend. An app that only stores data on the device is a fundamentally smaller job than one with accounts, a server, and data syncing between them. Accounts alone bring sign-up, sign-in, password reset, deletion, and a privacy obligation.

How many kinds of user there are. One user type is simple. A customer and an admin is roughly double, because every screen now has a permissions question attached.

What it has to talk to. Integrations with a CRM, a payment provider, a scheduling tool or an existing database are usually where estimates go wrong, because you inherit someone else's constraints and their downtime.

Whether it works offline. Handling a lost connection gracefully is a real architectural decision, not a setting. If people will use your app in a basement, a warehouse or on a plane, say so early.

Payments. Taking money inside an app means Apple's in-app purchase rules, subscription states, restoring purchases, and receipt validation. It is rarely the day of work people expect.

Hourly and fixed are not the same deal

An hourly rate transfers risk to you. If the work takes twice as long, you pay twice as much, and the developer has no particular incentive to find that out early.

A fixed price transfers risk to the builder, which is why anyone quoting fixed will insist on scoping first. That scoping is not a delay tactic. It is the part where the unknowns get found while they are still cheap.

Neither is automatically better. What matters is that you know which one you are in, and that a fixed price is not being quoted off a paragraph.

What a real quote tells you

A quote worth acting on says what version one includes and, just as importantly, what it excludes. It should name the platforms, say who owns the code, state what happens when you want a change mid-build, and cover who handles App Store submission and what happens if Apple rejects it.

If a quote is a single number with no scope attached, the number is not the problem. The missing scope is.

Before you ask anyone for a price

Write down what the app must do on day one, who uses it, and what happens today without it. That last question is the useful one: it tells a developer what problem they are actually solving, which is what makes an estimate mean anything.

You do not need a spec. You need the problem stated clearly enough that someone can ask good questions about it.