"How much would an app like this cost?" is almost always the real first question behind the first email we get, even when it's phrased as something else. "It depends" is the honest answer — but it's not a useful one on its own, so this is what it actually depends on, in the order it usually matters.
Scope, before anything else
The single biggest lever isn't the platform or the tech stack — it's how much the app actually needs to do in its first shippable version. A single-screen utility that does one job well is a fundamentally different project from an app with accounts, a backend, multiple user roles, and real-time sync. Most of the cost variance between projects comes from scope, not from anything technical. This is also the lever most within a client's control: a smaller, sharper first version is usually both cheaper and the better product decision — see our post on why focused apps beat bloated ones.
Does it need a backend?
An app that only stores data on-device is a different quote than one that needs user accounts, a server, a database, and an API. Backend work isn't just "more code" — it adds ongoing hosting costs, security considerations, and a second system that has to be maintained alongside the app itself. If your idea can work fully on-device for a first version, that's often the fastest and cheapest way to validate it before committing to backend infrastructure.
How much design work is actually needed
Some projects arrive with a clear visual direction or existing brand guidelines; others need the interface designed from a blank page. Design isn't a rounding error on top of engineering — for a consumer-facing app, it's often close to half the actual work, because the interface is the product as far as most users are concerned.
What "done" needs to include
A quote for "the app" and a quote for "the app, submitted, live on the App Store, with working analytics and a support channel" are different numbers. The unglamorous parts we wrote about in what actually slows indie apps down — metadata, screenshots, privacy compliance, TestFlight testing — take real time, and it's worth deciding upfront whether that's inside the project scope or handled separately.
Fixed price vs. time-and-materials
For a well-defined first version with a clear scope, a fixed price is usually the right structure — you know the number before work starts, and the risk of scope estimation sits with us, not you. For a project that's genuinely exploratory, where the right feature set will only become clear once you see the first version in front of real users, time-and- materials with a not-to-exceed ceiling is often the more honest structure, because it doesn't force premature decisions just to fit a fixed quote.
What doesn't move the number much
A few things clients often worry are expensive but usually aren't the deciding factor: which specific iOS version you want to support, whether the app needs dark mode, or whether it needs to work on iPad as well as iPhone. These are real work, but they're small relative to scope and backend complexity — worth mentioning early, but rarely worth agonizing over before that first conversation.
The fastest way to get an actual number, rather than a range, is to describe the one core job the app needs to do in its first version and whether it needs to talk to a server. That alone gets us most of the way to a real quote.