Mobile app development cost: why three quotes for the same app never match

Three quotes, one brief

It usually goes like this. The brief has the screens everyone agreed on: sign in, a dashboard, a booking flow, a profile. It goes to three vendors. A week later the quotes arrive, and the highest is several times the lowest.

The natural reaction is to assume someone is padding the number. In our experience that is rarely what happened. The screens were the same in all three quotes. Everything behind them was not.

A brief describes what the user sees. The cost sits in what the user never sees: who can sign in and how, where the data comes from, what happens when there is no signal, and what the people running the service need on their side. When the brief leaves those questions open, each vendor answers them quietly, in its own way, and prices its own answer.

We design and build mobile apps, so we have an interest in how they are bought, and you should read this with that in mind. We read the nine pages ranking for this question on 9 October 2026. All nine were written by agencies or vendors, and all nine published a price band, from around 10,000 to more than 500,000 US dollars, that disagreed with the others. The yearly maintenance figure they quoted ran from 15 to 50 percent of the build, and none of them named a source for it. So the figures below come from published data with a stated method, not from us, and the rest of the article is about why your own quotes differ.

So what does mobile app development actually cost?

You came here for a number, so here is the most honest one we know. Clutch, the review platform, publishes pricing from the app projects its clients review. In its guide updated in September 2026, most of those projects cost between 10,000 and 49,999 US dollars. The average project cost 90,780 US dollars and ran for about 11 months, which works out at roughly 8,190 dollars a month.

Read those two figures together. When the average sits that far above the typical band, a long tail of much larger projects is pulling it up. Small apps with a handful of screens and no integrations fill the typical band. Business apps for mid-size and large organisations, with a real backend, single sign-on and connections to an ERP or CRM, live in the tail.

The rest of the number is people and time. Every quote, however it is presented, comes down to how many people work on the app, for how many weeks, at what rate. Clutch puts the typical agency rate at 25 to 49 US dollars an hour, and its own table shows how much that moves by country: under 25 dollars in India, 50 to 99 in Canada and Poland, 100 to 149 in Australia. For a sense of what in-house costs, the US Bureau of Labor Statistics put the median software developer’s pay at 135,980 US dollars a year in May 2025, before benefits and overheads.

Here is how that arithmetic looks, as an illustration rather than a quote. Four people for six months at 40 dollars an hour is about 4 people × 26 weeks × 40 hours × 40 dollars, or roughly 166,000 US dollars. Halve the team or the timeline and the number halves. Double the rate and it doubles. That is why the questions in the next section matter more than any range: they decide how many people you need, and for how long.

What sits behind the screens

Behind a business app sits the work that makes it useful. This is where quotes split, because a vendor can assume it already exists, or leave it out, without saying so.

The backend is the big one: accounts, roles, business rules, notifications, file storage, and an API that keeps older versions of the app working when the backend changes. Then come the integrations with what you already run, such as an ERP, a CRM, payments, maps or your identity provider. Each of those is a small project with its own testing.

Large organisations add their own layer. Staff sign in through single sign-on, and internal apps are often distributed through device management rather than the public stores. And there is almost always an admin side for the people who run the service, which can be as large as the app itself.

Offline is the one people forget. Storing data on the phone, queuing changes and settling what happens when two people edit the same record is real work, so name the places where signal is poor before anyone quotes.

If your systems already expose clean APIs, this part shrinks. If the data lives in spreadsheets, or in a system with no API, it grows, sometimes past the app itself.

How one client settled it before the build

A consumer app company in Egypt came to us wanting a step counter app. The easy move would have been to quote the screens they showed us. Instead, the project started with several discovery meetings, and by the end of them the goals, the deliverables, the features, the tasks, the deadlines and the cost were all written down before anyone wrote code.

One decision from those meetings did more for the budget than any other: build Android first, and do iOS later. That is a scope decision, not a discount, and because it was made up front, the number everyone agreed to was the number the project ran on. The client later told Clutch the app reached a 4.7 rating on Google Play after 20,000 installs, and that the updates came almost daily.

The lesson is not that every app should start on one platform. It is that the questions behind the screens get answered by someone. If you answer them in the brief, every vendor prices the same app. If you leave them open, you get three quotes for three different apps.

Native, cross-platform, or one platform first

People often expect iOS to cost more than Android, or the other way round. By Clutch’s data the platform barely changes the hourly rate. What changes the total is how many apps you are really building.

Two native apps, one in Swift for iOS and one in Kotlin for Android, are close to two projects, each with its own code, testing and releases. Cross-platform frameworks such as React Native and Flutter share most of the code between the two, which is why they are usually cheaper for business apps. They are not free: both frameworks document the platform-specific code that remains for camera, payments, background work and anything else the shared layer cannot reach.

The third route is the one from the story above: one platform first, chosen by where your users are, and the second once the first has proved itself. Our native, cross-platform or web app comparison sets the routes side by side.

Where design fits in the number

Design is not a coat of paint at the end. On a well-run project it is where most of the open questions get answered, because drawing the screens forces decisions about who sees what, and what happens when something goes wrong.

When a cashback rewards app hired us for its UI and UX, the work ran from a discovery meeting and a look at competing apps, through user research and personas, to wireframes, interactive prototypes, the visual design and developer-ready files. The client later told Clutch that their store ratings and time in the app went up and complaints went down. They also told Clutch what they would have liked more of: more frequent progress updates, and more explanation of why each design decision was made.

That second point is worth taking into your own project. Ask any vendor to show you the reasoning behind the design, not just the screens. It is the cheapest moment to change your mind. If you want the app designed and tested before you commit to a build, mobile app design can be bought on its own.

How long it takes

Clutch’s average app project runs for about 11 months, and the shape of that time matters more than the total. Discovery and design come first, and they are the part people try to rush. Then the build, usually in short cycles you can see and test. Then testing on real devices, which takes longer than anyone plans for.

Then the stores. Apple says App Review typically looks at half of all submissions in under 24 hours and 90 percent in under 48. Google Play says reviews can take up to seven days, or longer in exceptional cases. An incomplete submission is slower at both, so plan the launch date around review, not around the last day of development.

Fixed price or time and materials

Vendors will offer you one of two models, and each fits a different kind of brief.

A fixed price suits a brief that has answered the questions in this article. You know the users, the systems, the platforms and the first release, and you want one number to take to your board. The risk is change: anything outside the agreed scope becomes a change request, so the scope has to be written down properly.

Time and materials suits a brief that is still moving, where you would rather pay for the work done each month than argue about what was in scope. The risk there is drift, so it needs a clear backlog, regular demos and someone on your side who decides what comes next. Many projects use both: a fixed price for discovery and design, then time and materials for the build once the scope is clear.

The work Apple and Google require, quoted or not

Some work is required by the stores whatever your brief says. It is easy to leave out of a quote and expensive to discover at submission.

The accounts and fees are small but belong in the plan. Apple’s developer program is 99 US dollars per membership year, and Google Play has a one-time registration fee of 25 US dollars. Put both accounts in your organisation’s name, not the vendor’s.

If the app sells digital goods or subscriptions, the stores take a commission, and it is not always 30 percent. Apple charges 15 percent to developers in its Small Business Program, which is open to those with up to 1 million US dollars in proceeds in the prior year. Google Play charges 15 percent on a developer’s first 1 million US dollars of revenue each year and on renewing subscriptions, and 30 percent above that, with different rates in some regions. Settle this before you set your prices.

Accessibility belongs in the brief too. The W3C’s guidance on applying WCAG 2.2 to mobile covers native, mobile web and hybrid apps, so the standard you already name for your website can be named for the app.

An app is a yearly cost, not a one-time one

This is the part most quotes skip. An app that is not updated stops being publishable, because Apple and Google raise their minimum requirements every year.

Right now, apps uploaded to Apple must be built with Xcode 26 or later, using the iOS 26 SDK, a rule in force since 28 April 2026, and since 9 September 2026 they must target iOS 13 or later. On Google Play, new apps and updates must target Android 16 from 31 August 2026, with extensions to 1 November 2026 on request, and existing apps must target Android 15 to stay available to new users. Each step can mean updated libraries, changed permissions and a fresh round of testing.

The stores watch quality as well. Google Play treats a user-perceived crash rate of 1.09 percent of daily users, or an app-not-responding rate of 0.47 percent, as bad behaviour, and says an app above those lines is likely to be less discoverable. Apple warns developers of apps that have not been updated in three years and are barely downloaded, gives them 90 days, and removes apps that crash on launch straight away.

You will see a rule of thumb that maintenance costs 15 to 20 percent of the build each year. We could not find a primary source for it on any page that repeats it, and it cannot know how much your app connects to. Price the running cost from the work instead.

So budget for a second year as well as the first: the platform updates, tested against the betas rather than after launch day; the SDKs for payments, maps and sign-in, which change on their own schedule; the backend’s hosting and security patches; someone watching the crash rates; and your own team’s time to plan releases.

How to bring the cost down without breaking the app

Most of the ways to spend less are scope decisions made early, not discounts negotiated late.

• Start on one platform, the one most of your users carry, as the step counter app did.
• Use a cross-platform framework if the app does not lean hard on the camera, background work or heavy graphics.
• Ship the smallest version that tests the idea, then add to it. What MVP development costs explains how to size it.
• Reuse the backend and the APIs you already have rather than building new ones for the app.
• Launch with fewer kinds of user. A customer side and an operations side are close to two products.
• Settle the questions in discovery. Every question answered on paper is one nobody pays to answer in code.

The one place not to save is testing on real devices. A crash rate above Google’s threshold costs you visibility on the store, which is far more expensive than the testing would have been.

How to ask for quotes you can compare

The fix is simple, if a little tedious. Put the same questions in front of every vendor and ask them to answer each one in one of three ways: priced, excluded, or assumed to exist already. The third answer is the one to watch, because a backend or an integration assumed to exist is work nobody has priced.

• The route: native, cross-platform, or one platform first.
• Every kind of user, what each can do, and what each must never see.
• The backend and API, and which parts the vendor builds.
• Each integration, named.
• Sign-in, including the alternative login and in-app account deletion.
• Where the app must work offline.
• The admin side, priced as part of the app.
• Store compliance and accessibility, with the standard named.
• The oldest iOS and Android versions to support.
• Who owns the developer accounts, the code, the signing keys and the hosting.
• The first year after launch: updates, monitoring and response times.

Then compare what each quote leaves out before you compare the totals. The cheapest quote is often the one that answered “assumed to exist” most often.

When you do not need an app at all

Some of the spread between quotes is really a disagreement about whether you need an app. If people will use it occasionally, at a desk, and need nothing only a phone can do, a web application does the job with no store review and no yearly platform cycle.

The same goes if nobody will maintain it, because it will fall below the stores’ floors within a year or two, or if the data it needs is not reachable through an API yet. Fix the backend first. The app will only ever be as reliable as what it talks to.

And if the first version is really a test of whether people want the product, a designed mobile app prototype or an MVP answers that for far less.

If you are holding app quotes that do not match, send them to us with the brief. The people who would design and build the app will tell you which questions each quote left open, whether or not you hire us.