How much does it cost to build a mobile app? A realistic budget from idea to App Store

You have an app idea and three numbers. One developer says eight thousand. An agency says seventy. A firm with a slide deck says the first phase alone is three hundred, and nobody has explained how the same idea can be all three at once.

So: how much does it cost to build an app? Most business apps cost between $25,000 and $150,000 to build, and roughly 15 to 25 per cent of that again every year to keep alive. Below that band you are buying either a wrap of a website you already have or a deliberately narrow first version. Above it you are funding a platform rather than an app. The number is decided far more by what has to exist behind the app than by how many screens are in front of it, which is why the quotes vary so wildly: each supplier has guessed differently about the invisible half.

How much does it cost to build an app? The short answer, by band

To place yourself, ignore the feature list for a moment and ask how much of what the app needs already exists. A business with a modern website, a real database and a way for other software to talk to it is starting halfway up the table. A business whose systems are a spreadsheet and a booking phone is buying two products, not one. If the general question of why quotes differ so much is what is bothering you, our guide to what a website costs and what moves the price covers that logic in more depth; the app-specific version is below.

What actually drives the price

A handful of things move an app budget far more than the feature list does. This is roughly the order they come up in when we scope customer apps, and the first one is the one almost nobody expects.

• The backend, not the app. This is the one nobody expects. An app is usually two products: the thing on the phone, and the server it talks to, which holds the accounts, the data, the rules and an admin screen for your own team. If you already have a website with a real interface for other software to use, much of that exists. If not, the invisible half is frequently the larger half of the bill.
• Accounts, roles and permissions. Sign-up, sign-in, forgotten passwords, verification, and account deletion inside the app, which both stores now expect if you let people sign up at all. This is a fixed foundation cost that arrives whatever your idea is, and it is why nothing serious starts at a few thousand.
• Offline. The most underestimated multiplier in mobile. "Works on a train with no signal, then sorts itself out when the signal comes back" is a genuinely different product from "works on wifi", because now two copies of the truth exist and something has to decide which wins. If field staff will use it, price this properly.
• Payments, and which kind. Taking a card for a physical product is straightforward. Selling digital subscriptions or credits inside the app pulls in the store rules, the store commission and a second set of receipts to reconcile. See the store section below, because this is the point people get wrong most expensively.
• Real-time anything. Live tracking on a map, chat, video, presence. Each of these is a small project on its own, and they are usually the difference between the third band and the fourth.
• Integrations. Every system the app has to speak to, and whether it has a documented way to be spoken to. Same rule as websites: a documented interface is days, an undocumented one is a project.
• Design. An app assembled from each platform's standard components is cheap and looks like everything else. One that feels like your brand costs weeks of design plus the build to match it. Both are legitimate; only one of them is what most people picture when they say app.
• Screens, last. Screen count matters least, because twenty screens built from four patterns cost far less than six that are each invented from scratch.

One codebase or two, and what that really saves

You can build an app twice, once in Apple's language and once in Google's, or once in a shared framework such as React Native or Flutter that produces both. For the great majority of business apps the shared route is the right call, and the saving is typically a third to a half against building the same thing natively twice.

The larger saving arrives later. Every change you ever make afterwards happens once rather than twice, in one place, tested once. Over three years that compounds into more than the difference in the original build.

One honest correction, because it is the most common misunderstanding in app quoting: a single codebase is cheaper than two native apps, not cheaper than one. If a supplier offers both platforms for the price of a single-platform quote elsewhere, the question is not how they are so efficient. It is what is missing from the scope.

Native still earns its cost in specific cases: games and heavy graphics, sustained camera or sensor work, anything where performance is the product, and situations where you need a brand-new operating system feature on the day it ships. Outside those, the shared codebase usually wins on every axis that matters to a business.

The store paperwork nobody puts in the quote

• The developer accounts. Apple's programme is an annual membership, $99 at the time of writing, and it recurs: let it lapse and your app comes off the store. Google's is a one-off registration fee, $25 at the time of writing. Small money, but both must be in your company's name, not your developer's, for reasons the rest of our writing on ownership should make obvious.
• The tester rule that ambushes founders. New personal Google Play accounts, created since late 2023, must run a closed test with at least twelve testers opted in continuously for fourteen days before the app can go to production. Organisation accounts are exempt. People discover this in the week they planned to launch. Register as an organisation, register early, and start recruiting testers long before the app is finished.
• Review. Updates usually clear in a day or two. A brand-new app normally takes longer, and rejection is common enough that a sensible plan assumes one round rather than hopes for none. Wrapped websites with nothing a browser could not do are rejected on principle, privacy declarations are enforced strictly, and metadata mistakes bounce a build before anyone looks at the code. Budget a couple of weeks and treat approval as a reviewer's judgement, which nobody can promise you.
• Commission, and the part that is genuinely misunderstood. Digital goods sold inside an app (subscriptions, credits, premium features) carry a store commission. The rate for smaller developers has been 15 per cent, with a higher standard rate above that, and the numbers are moving in several regions as court cases and regulators land, so check the current figure for your market. What matters far more for most businesses reading this: physical goods and real-world services are not charged at all. A restaurant taking food orders, a clinic taking bookings, a retailer selling stock, a trades firm taking deposits: the stores take nothing, and in fact forbid you from using their in-app purchase for those. You use an ordinary card processor and pay ordinary card fees.

Getting an app through submission cleanly is a skill of its own, which is why we treat app store launch as a named piece of work rather than the last afternoon of the project.

What it costs after launch

An app is not a website. A website you neglect quietly goes stale. An app you neglect actually breaks, because the ground moves underneath it twice a year whether you are paying attention or not.

• Operating system releases. Apple and Google each ship a major version annually, and each one can require changes: things that were allowed stop being allowed, interfaces shift, older builds start looking wrong or refusing to run.
• Devices. New screen sizes and hardware arrive constantly, and someone has to check the app still behaves on them.
• The backend. Hosting, the database, and the third-party services the app depends on: notifications, maps, search, messaging, file storage.
• Crash monitoring and analytics, without which you learn about problems from one-star reviews.
• Store accounts and certificates. The Apple membership renews annually; signing certificates expire on their own schedule and take releases down with them when nobody is watching.
• Support and small improvements, because customers ask for things and the good ones are usually cheap to add.

As a rule of thumb, budget 15 to 25 per cent of the build cost per year, and expect the first year to sit at the top of that as the real-world edges get sanded off. An app nobody maintains does not stand still; it degrades, and the cost of restarting it later is always higher than the cost of keeping it alive.

A realistic timeline

1. Shaping and design, two to six weeks. What it does, for whom, what the first version deliberately leaves out, and what the screens look like. Change your mind here, where it costs nothing.
2. Build, in two-week pieces. At the end of every one there should be something you can hold on a real phone. A supplier who disappears for three months and returns with a reveal is taking a risk with your money rather than their own.
3. Internal testing. Your team and a pilot group on real devices through Apple's TestFlight and Google's closed track, which is also where the twelve-tester clock runs if it applies to you.
4. Submission and review, with at least one rejection round assumed in the plan.
5. Launch, then a fortnight of small fixes, because real users always find the thing nobody tested.

What actually causes slippage is rarely the code. It is decisions and content on your side, and the two things outside everyone's control: the tester requirement and the review queue. Both are predictable if you start them early and neither can be hurried by paying more.

How to spend less without building rubbish

• Build the narrow version. One kind of user, one job, done well. The feature list you arrive with is usually two or three times the size of the version that should launch first, and the cut features are cheaper to add once real people have told you which ones they wanted.
• Use the backend you already have. If your website has real data behind it, the app may be able to talk to that rather than to something new.
• One codebase. For most business apps this is simply the correct answer.
• Do not build accounts you do not need. Let people use the thing first and sign up when there is a reason to. It removes an entire foundation cost and improves the numbers at the same time.
• Buy the standard parts. Sign-in, payments, chat, maps, crash reporting and analytics are all solved. Paying a small monthly fee for a solved problem is nearly always cheaper than building and then maintaining your own.
• Prototype the screens before anyone writes code. A clickable version that people can try costs a fraction of the build and is the cheapest place in the whole project to discover you were wrong.

Not for you if

Questions to ask any app developer

1. What backend is in this quote, and what are you assuming already exists on our side?
2. One codebase or two? If two, what are we getting for the second one?
3. Which of these screens are unique designs, and which come from a standard component kit?
4. Does the app need to work without a signal, and is that priced in here?
5. What administration screens will our own team need, and are they in this number?
6. Will the store accounts, signing keys and code be in our name?
7. What is your assumption about store review, and who handles a rejection?
8. What will year two cost us, in money and in your involvement?
9. Which of the post-launch costs are included and which will be invoiced?
10. If we stopped working with you after launch, what would the next team need, and do they have it?

The decision you are actually making

You are not choosing between three prices. You are choosing how much invisible machinery to commission, and whether you need any of it before you have proof that people will install the thing. The cheapest successful app is nearly always the narrow one that launched, got used, and earned its second version. The most expensive is the complete one that was right about everything except what customers wanted.