How much does it cost to build an app? What the data says

Most app projects reviewed on Clutch cost $10,000 to $49,999, and the average project is $90,780.11 over about 11 months, according to Clutch's app pricing guide (updated 21 September 2026, checked 1 November 2026). How much it costs to build your app comes down to the hours your features take and the hourly rate of whoever builds them. This post compares the public data, shows why published ranges run from free to $500,000, and breaks down the four features with the most hidden work in apps we've shipped: sign-in, subscriptions, AI and ads. We don't publish our prices here.

What does the public data say about mobile app development cost?

Three public sources are worth reading. None of them publishes a full method, so treat each figure as a rough marker.

All figures checked on 1 November 2026.

Two things stand out in the Clutch numbers. First, they hang together: 11 months at $8,188.44 a month is $90,072.84, close to the stated average. Second, the average sits well above the typical band. Our reading is that a minority of large, long projects pulls the average up, so if you're planning a first version, the $10,000 to $49,999 band is the closer comparison. Clutch doesn't say how many reviews sit behind either figure.

Clutch also lists hourly rates by country. It puts the United States, the Philippines, Ukraine, Spain and Mexico at $25 to $49, and marks the UK "Unknown". Canada and Poland sit at $50 to $99, Australia at $100 to $149 and India under $25. That US band is below Accelerance's senior rates for Europe and Latin America, and Clutch gives no count of firms behind each row, so read any one country's figure as a hint.

Why do app cost estimates run from free to $500,000?

Because cost is hours times rate, and both vary several times over.

Rates first. In Accelerance's survey, a senior developer costs $31 to $41 an hour in Asia and $64 to $76 in Europe. Same seniority, roughly double the price.

Hours vary more. The same idea can be a 3-screen app with no accounts, or a product with sign-in, subscriptions, an admin panel, AI features and ads. Quotes also differ on what's included: design, the backend, testing on real phones, the store release and the first weeks of fixes are sometimes in and sometimes left out.

Platform choice is the third lever. Clutch says that "creating one native iOS app and a native Android app will double the overall price of your app development project." A cross-platform framework such as Flutter avoids most of that doubling, though not all of it. We cover where it doesn't in Flutter or native? When we would tell you to go native.

Here's the arithmetic. The hours are made up to show the spread; the rates are the ends of Accelerance's senior bands (low end for Asia, high end for Europe).

The cheapest and dearest cells are about 15 times apart ($228,000 / $15,500 = 14.7). Only the scope and the rate changed. That's why a single "average app cost" tells you so little until you know which features you need.

What makes an app expensive? Four features from apps we've shipped

In apps we've shipped, four features held far more work than their one-line description suggests: sign-in, subscriptions, AI generation and ads. Each one turns into a list of smaller jobs, plus a monthly bill or a store rule.

Sign-in and accounts

The login screen is the smallest part of sign-in. Most of the work sits in what happens before and after it. In our apps, that came down to five jobs:

• Every user starts as an anonymous guest, so they can try the app before signing up. When they sign up with Google or email, the guest account is linked to the new one, and their history and usage carry over. The edge cases (an email that already has an account, a Google account already linked elsewhere) each need their own path.
• Google sign-in on Android needs the app's SHA-1 and SHA-256 fingerprints registered for the debug key, the release key and Google Play's app signing key. Miss the last one and sign-in works on builds you install yourself, then fails for everyone who installs from Google Play.
• Both stores want account deletion. Apple's guideline 5.1.1(v) says that if your app supports account creation, you "must also offer account deletion within the app". Google Play asks for an in-app path and a web link where users can request deletion. Firebase only deletes an account if the user signed in recently, so the flow has to re-authenticate first (an account picker or a password prompt). Skip that and the app ends up telling users to log in again and retry, which in practice means the account never gets deleted.
• After logout, the app has to start a fresh guest session straight away. In one of our apps, the empty session in between read as a brand-new user, and the free allowance reset to full on every logout.
• When a different person signs in on the same phone, the previous account's local data has to be cleared, and the database rules have to stop one user reading another's records. Those rules protect nothing until they're deployed to the live project.

On iOS there's one more rule. Apple's guideline 4.8 says an app that uses Google Sign-In or another social login for the main account "must also offer as an equivalent option another login service" that limits data collection to the user's name and email address, lets users keep their email private, and doesn't collect app interactions for advertising without consent.

What makes it smaller: email only, or no accounts at all. An app without accounts can still sell subscriptions, because the store account handles restores.

Subscriptions and in-app payments

On iOS, in-app purchase is the default for digital features. Apple's guideline 3.1.1 says that to unlock features or functionality, including subscriptions, "you must use in-app purchase." Guideline 3.1.1(a) now lets apps on the United States storefront add buttons and links to other ways to pay, and apps in some other regions can apply for a link-out entitlement. For most apps, in-app purchase is still the only method that works in every storefront, so it's the one you build.

In our apps, with RevenueCat on top of the store billing, the work was:

• One premium status that every part of the app reads: the paywall, the usage limits and the ads. The app caches that status and waits for it before deciding anything, so a paying user isn't shown an ad just because the ad loaded first.
• Restore after a reinstall, "already owned" errors, cancelled and pending purchases, and a success screen that hands the user back to what they were doing.
• Store quirks. On Android a subscription can arrive as the product ID plus the base plan ID. One of our database rules rejected the longer form until we listed both.
• Testing with licence testers: buy, cancel, restore on a second install, and log out then in with another account.

Running costs, checked 1 November 2026:

• Apple's Small Business Program takes 15% on paid apps and in-app purchases for developers new to the App Store or with up to $1 million in proceeds the previous year.
• Google Play's service fee page lists 15% for auto-renewing subscriptions in markets outside its new regional table. That table started on 30 June 2026 for the US, UK and EEA (30 September for Australia and Japan), and there subscriptions are 10% plus a 5% billing fee.
• RevenueCat is free "for up to $2,500 in monthly tracked revenue", then 1% of what you track.

What makes it smaller: one plan, or a one-time unlock. Each extra plan, trial or promotional offer adds store setup and test cases on both platforms.

AI features

An AI feature has two costs: the build, which is mostly the work around the model, and a per-use bill that grows with your users.

Here's what sat around the model in our apps:

• The model runs behind our own backend. The app never holds an API key, and the server picks the model, so switching models or providers doesn't need an app update.
• We ask the model for JSON, then parse it defensively because models wrap it in code fences or add commentary. Lengths and counts are checked after the fact, and text that's too long for its box gets trimmed in code. A prompt is a request; the code is what enforces it.
• Failed calls retry with backoff, re-ask only for the missing parts, then fall back to a second provider. A network failure has to show up as an error. Swap it for placeholder text and a half-filled result gets saved and counted.
• Usage limits: a lifetime limit for guests, a daily limit for free accounts, no limit for subscribers. A generation is counted only after the result is saved. If the connection drops mid-generation, the run is cancelled at once, nothing is charged, and a late reply is thrown away.
• Reporting: Google Play's AI-generated content policy requires apps to "allow users to report or flag offensive content to developers without needing to exit the app."

For the running cost, here's an example with made-up usage and Google's published price for Gemini 2.5 Flash: $0.30 per million input tokens and $2.50 per million output tokens (Gemini API pricing, page updated 30 October 2026, checked 1 November 2026).

1. One generation sends 3,000 tokens and gets 1,500 back.
2. Input: 3,000 × $0.30 / 1,000,000 = $0.0009.
3. Output: 1,500 × $2.50 / 1,000,000 = $0.00375.
4. Total: $0.00465 per generation, under half a cent.
5. At 10,000 generations a day, that's $46.50 a day, or about $1,395 over 30 days.

Prices also move. The same page lists Gemini 3.8 Flash input at $0.75 per million tokens through 31 December 2026 and $1.50 from 1 January 2027. That's one more reason to keep the model choice on the server. We cover the backend side in more depth in how to add AI features to an existing app.

What makes it smaller: one AI feature with one output format, and a fixed daily cap per user, which also puts a ceiling on the token bill.

Ads

Ads look like the cheapest feature to add, and they're the one that has earned us policy notices.

What ads involved in our apps:

• Consent: Google's consent requirements say that "as of 16 January 2024, a certified CMP integrated with the TCF is required" when serving personalised ads to users in the EEA and UK, and Switzerland followed on 31 July 2024. We use Google's own User Messaging Platform SDK, and every ad request checks consent first.
• Placement: we've had an AdMob notice for interstitials that appeared between a tap and the screen it opened, and another for native ads that lacked a visible "Ad" label and sat among the app's own content. Both were code fixes, so both meant a new release. The native-ad notice also applies to older versions still on people's phones, so users had to be asked to update.
• No ads for subscribers, checked when the ad loads and again when it shows.
• Test ads in debug builds, because live ads tapped during testing count as invalid traffic.
• Store paperwork: "Contains ads" in Play Console, the advertising ID declaration, the data safety form and an app-ads.txt file on your website.

What makes it smaller: banners only, in fixed places. Rewarded ads that unlock an action need an opt-in dialog each time and a fallback when no ad loads, so the user is never stuck waiting.

What else does every app pay for, whatever its features?

Store accounts, a store's release rules and a yearly platform update. These are small next to the build, but they land on the schedule.

The target API rule moves every year, so plan an update even if you add nothing new. An app that stops being updated eventually can't ship fixes until it catches up.

How can you tell whether an app quote is reasonable?

Break it into lines you can check. A single total can't be compared with anything.

1. Ask for hours against each feature. A good brief makes this easy; we have a brief template for exactly this.
2. Check what's excluded: design, backend, admin panel, testing on real phones, store release, fixes after launch.
3. Divide the total by the hours. Compare the rate with the Accelerance band, or Clutch's country table, for where the team is based.
4. Look for the hidden lines from the four features above: account deletion, restore purchases, a consent form, usage limits. If they're missing, the quote is for a smaller app than the one you described.
5. Ask whose name the Apple, Google and cloud accounts will be in. They should be yours.
6. Ask for the monthly running costs as a separate list: store fees, backend, AI tokens, subscriptions tooling.

When shouldn't you build an app yet?

When a website or a prototype would answer your question for less.

• Your idea is mostly content. Apple's guideline 4.2 says "your app should include features, content, and UI that elevate it beyond a repackaged website." If yours wouldn't, start with a website.
• You haven't tested demand. A clickable prototype or a builder-made demo can show whether people want it before you pay for store releases and accounts.
• Your budget only covers the build. Store fees, backend, tokens and the yearly update keep coming. If you can't carry those for a year, cut scope until you can.

What we would do

For most first versions, we'd build one Flutter codebase for both stores, unless the app depends on heavy platform work such as video editing or low-latency audio. Then we'd cut the four expensive features down to what the business model needs:

• Guest access plus one sign-in method, or no accounts if the app doesn't need them.
• One way to make money. If the app has an AI feature with a per-use bill, tie AI use to a plan or a daily limit from day one rather than hoping ads cover it.
• Ads only if the app has natural breaks in use, and only with the consent flow built in.
• AI behind your own backend, with limits and a switchable model.

The condition: this assumes a first version meant to prove demand. If you already have paying users and a tested flow, the trade-offs change, and native work or a second plan may be worth it. Our mobile app development work begins with a scope call and a fixed written plan, so these trade-offs are settled before any code is written.

Your next step

Write your feature list and mark each line that touches sign-in, payments, AI or ads. Then ask every team you talk to for hours against each marked line. If a quote can't be split that way, it isn't an estimate yet. When your list is ready, you can send it to us or to hello@zoftaa.com, and we'll start with a scope call.