If you’ve started researching what a mobile app costs, you’ve probably noticed that the answers don’t agree. One guide gives you a range, the next gives you a different one, and when you finally send the same idea to a handful of agencies, the quotes come back so far apart that it’s hard to believe they all read the same document. Another dollar range won’t help much with that.

So this post skips the ranges and walks through the variables that move the number for your app, roughly in order of how much leverage each one has, so that when quotes arrive you can read them critically and see why they differ. It’s the page we’d want a client to read before they ask anyone for a price, including us.

The two most prominent cost guides on this search, from Appinventiv and Topflight, are both written by development shops, and both build their answer the same way. They estimate development hours, multiply by an hourly rate, and then slice the result by complexity, app category, platform, and region. Each slice is an average across every possible app that fits it, so the ranges are enormous: within a single category, the top of a range often sits five to ten times above the bottom, and the two guides don’t line up with each other either.

None of that makes the guides wrong. A simple app built by a small offshore team and a regulated healthcare platform built by a domestic team really do cost wildly different amounts, and a range wide enough to cover both is technically accurate. What a range that wide can’t tell you is where your own project lands inside it, and for that you need to know which variables apply to you and how heavily each one weighs, so let’s take them in order.

Scope is the biggest lever by a wide margin, and the most important scope decision is whether you’re building a first version to learn from or a complete product. A first version covers the one or two workflows that prove the idea, ships, and lets real users tell you what to build next. A full build tries to anticipate everything up front, which means paying to design and engineer features before anyone has used them. Two quotes for “the same app” are often pricing these two different things without either vendor saying so.

The second scope question is how many pieces of software you’re actually commissioning. A mobile app is rarely one codebase. In nearly every product we’ve worked on, it’s three connected pieces: the app on the phone, the backend and API it talks to, and a web surface, whether that’s an admin panel for your team or a full web application. We cover that shape in more depth in our post on San Diego mobile app development, and the cost implication is that a quote that only prices the screens in your mockup is leaving out the parts those screens depend on, and that work tends to come back later as a change order.

Platform is the variable most cost guides lead with, and it does matter. Building separate native apps for iOS and Android means two codebases, two sets of platform expertise, and two release processes to keep in step. A cross-platform framework like React Native lets one codebase serve both, and it can share logic with your web platform so a feature ships everywhere at once, which is how we build our own mobile work. There are apps where fully native development is the right call, usually ones that lean heavily on device hardware or platform-specific features, and a good vendor should be able to tell you plainly whether yours is one of them.

Even so, the backend is usually where the real engineering risk and the real cost live. The screens are what you see in a demo, while accounts, payments, permissions, data sync, and integrations with your other systems all run on the server. An app that shows a list of records from a database needs a modest backend. An app that takes payments, syncs changes made offline, talks to a third-party system of record, and enforces different permissions for different roles needs a substantial one, even if its screens look nearly identical to the first. When you’re comparing quotes, ask each vendor to describe in a paragraph the backend they’re planning to build. The answers usually explain a large share of the price difference, and if a vendor can’t describe it yet, they haven’t scoped your project far enough to quote it.

Two vendors can quote the same scope, both honestly, and still cost you very different amounts over the life of the project, because the shape of the team changes what you’re really paying for. A solo contractor often has the lowest rate, and for a well-defined project with a capable person that can work well. The effective cost rises when that person gets sick, takes on another client, or moves on, and nobody else knows your codebase. A larger shop carries more overhead, but it should also give you code review, a second engineer who understands the system, and someone who can step in when the first one is out. An offshore firm can bring the hourly rate down, and the trade usually gets paid in reduced time-zone overlap and in how much day-to-day management ends up on your plate.

We’ve written about these trade-offs at length in our posts on hiring a Rails consultant and choosing a Ruby on Rails development company, including the questions that expose continuity and bench risk before you sign. They apply just as well when you’re hiring for a mobile project, because the backend behind your app carries the same continuity risk whichever team builds it.

Quotes tend to stop at launch day, and budgets often stop there too. But an app in the stores keeps needing work whether or not anyone planned for it. Apple and Google keep shipping operating system changes on their own schedule, and the frameworks and libraries under your backend keep moving as well, so an app nobody maintains gradually stops working the way its users expect, and the fixes tend to arrive as emergencies.

The useful question to put to any vendor is what ongoing maintenance looks like and who will do it. On the backends we look after, major Rails and Ruby upgrades ship with zero downtime, and our posts on the Rails maintenance retainer and taking over existing products describe what that ongoing commitment involves. Whether you work with us or someone else, put maintenance in the budget from the first conversation, so it never has to compete with a broken login screen the week after an OS update.

Once you understand what moves the number, the last step is making sure the quotes you collect are measuring the same thing. Ask every vendor on your shortlist the same five questions, and compare the answers side by side before you compare the totals.

1. What exactly is included? Ask for the screens, workflows, and backend pieces the price covers, and whether design, testing, and app store submission are part of it.
2. What is excluded? The gaps are often where two quotes differ most, and a vendor who can’t name any probably hasn’t thought hard about your project yet.
3. What happens when scope changes? It will, so find out how changes are estimated, approved, and billed before the first one arrives.
4. Who owns what after handoff? The code, the app store accounts, and the credentials should all be yours, and our post on choosing a mobile app development agency covers ownership in detail.
5. What happens after launch? Ask who maintains the app and the backend, how OS updates get handled, and how that ongoing work is arranged.

A quote that’s low because it leaves out testing and post-launch support and a quote that’s high because it includes them can describe exactly the same app. Once the answers sit side by side, the gap between two numbers usually makes sense. When it still doesn’t, go back to whichever vendor gave the vaguest answers and ask them to fill in the gaps before you decide.

A cost calculator can’t tell you what your app will cost because it doesn’t know which of these variables matter for you, so the estimate has to come out of a scoping conversation. When we start a new product, we begin by working through what you’re building, which of the three pieces it needs, and what a sensible first version looks like, and the estimate comes out of that conversation. Our new products page walks through how we approach builds from zero.

If you’d like to talk through your app before you start collecting quotes, book an intro call and bring whatever you have, even if it’s still a rough idea.