How much does it cost to build an app? What actually drives the price

"How much does an app cost?" is the first question almost every client asks, and "it depends" is the honest answer. That answer is useless on its own, though. What helps is knowing what it depends on — which decisions move the price a lot, which barely move it, and which costs keep arriving after launch.

This guide does not give you a price list. Any number written without your scope is a guess, and a guess that sounds like a quote does more harm than good. Instead, it walks through what actually drives the cost of building an app, so you can read the quotes you receive, compare them fairly and decide where to spend.

Why app quotes vary so much

Send the same idea to five developers and you can get five very different numbers. That is rarely because four of them are wrong. Usually they are pricing different things:

• Different assumptions about scope. One developer quotes the core flow; another quotes the core flow plus an admin panel, notifications and a store release.
• Different responsibilities. Some quotes include design, testing and the app store submission. Others assume you will handle those.
• Different risk buffers. A vague brief forces a developer to price in the unknowns. The clearer your brief, the smaller that buffer needs to be.
• Different experience. Someone who has built a similar system knows where the hidden work is. Someone who has not either misses it in the quote or finds it halfway through the project.

The fastest way to get comparable quotes is to send everyone the same short brief and ask what is included and what is not.

The biggest cost drivers

Platforms: iOS, Android and web

Building for one platform costs less than building for two, and a web dashboard on top is a third surface to design, build and test. Cross-platform frameworks such as React Native and Flutter let one codebase run on both iOS and Android, which is why most new apps for small teams start there. FeedSeek, for example, is a React Native app for iOS and Android, and Clearday is a Flutter app for both. If you are weighing the two, I compared them in React Native vs Flutter.

The number of user flows

Screens are a poor way to estimate an app. Flows are better. Signing up, creating something, paying, inviting a friend and recovering a password are each a flow, and each one touches the interface, the data and a handful of edge cases: what if the network drops halfway, what if the user goes back, what if two people edit the same thing.

A short list of flows that the app absolutely needs on day one is the single most useful document you can give a developer.

The backend and the admin side

Most apps need more than the app. They need somewhere to keep data, accounts and permissions, a way to send notifications, and often an admin side where you or your team manage what happens inside the product.

People underestimate the admin side more than anything else. FeedSeek is a good example: a platform where strangers hand each other food cannot rely on good intentions alone. Someone has to be able to pull a listing, and that is a server-side job with its own screens, not an afterthought.

Offline support and sync

An app that only works with a connection is simpler than one that works without it. SplitMate is offline-first because travel means bad signal: expenses and documents work with no connection and reconcile when the phone is back online. That is the right call for a travel app, but reconciling changes made on several phones is real engineering work. If your users are always connected, you can skip it.

Integrations

Every outside service you connect — payments, maps, calendars, email, SMS, WhatsApp, AI models — brings setup work, error handling and sometimes a review process on the provider's side. Each integration is usually modest on its own. Five of them add up.

AI features

AI can make an app feel remarkable, but it is not free to add well. A good AI feature needs a fallback for when the model is wrong, a way to keep the running cost per request under control, and testing against real inputs. ProAI Training uses three different model providers because holding a character in a live conversation, marking a transcript and writing lesson content are different problems. I wrote more about this in integrating AI into your app.

Design

A clean interface built from proven components costs less than a fully custom visual identity with bespoke animations. Both are legitimate choices. Decide which one your first version actually needs.

Testing, release and the app stores

Getting an app approved is its own piece of work: store listings, screenshots, privacy details, review notes, and fixes when a reviewer asks for changes. Make sure every quote you compare says whether the release is included.

The running costs people forget

Building the app is not the last bill. Plan for these from the start:

• Developer accounts. Apple's Developer Program is a yearly membership (US$99 per year at the time of writing), and Google Play charges a one-time registration fee (US$25). Both should be in your business's name.
• Hosting and the database. Usually modest for a new app, growing with usage.
• Usage-based services. AI APIs, maps, SMS and WhatsApp messages are typically billed per use. Since July 2025, for example, Meta bills the WhatsApp Business Platform per message rather than per conversation.
• Email, monitoring and backups. Small individually, easy to forget collectively.
• Maintenance. Apple and Google release new operating system versions every year, libraries move on, and stores change their rules. An app nobody maintains slowly stops working.

Ask every developer you talk to what they expect these to be for your app. A good one will give you the categories without being asked.

How to reduce the cost without cutting what matters

1. Build the smallest useful version first. One job, done well, released early. I wrote a whole guide on MVP development; it is the biggest lever you have.
2. Use a cross-platform framework. One codebase for iOS and Android is usually the right starting point unless you need something only native code can do.
3. Use managed services for the boring parts. Authentication, file storage and email delivery are solved problems. Pay for a service instead of building your own.
4. Phase the features. Payments can sometimes start manual. Social features can wait. Settings screens can stay small.
5. Decide early and change rarely. A change in week one costs minutes. The same change after launch can cost days.
6. Write a clear brief. Clarity shrinks the risk buffer in every quote you receive.

What you should not cut: whatever makes the product trustworthy. For FeedSeek that was moderation. For SplitMate it was making sure the balances always add up. Cutting the thing that makes people trust your app is the most expensive saving you can make.

How developers price projects

You will usually see one of three models:

• Fixed price for a defined scope. Predictable, but only as good as the scope document behind it.
• Hourly or weekly, billed as the work happens. Flexible, and fair when the scope is still moving, but it needs regular, visible progress.
• Milestones, with a price per stage and payment released when each stage is accepted. For a first project with a new developer this is often the best balance.

Whatever the model, each payment should line up with something you can open and try yourself.

How to compare quotes properly

When the quotes arrive, line them up against the same questions:

• What exactly is included — design, backend, admin side, testing, the store release?
• What is explicitly excluded?
• What is the first milestone you can click, and when?
• Who owns the code and the accounts at the end?
• What happens after launch, and what does support cost?

The cheapest quote is often the one that leaves the most out. The most expensive is not automatically the best. The right one is the quote whose scope matches your brief and whose developer asked you good questions on the way. If you are still choosing who to hire, the checklist in how to hire a freelance app developer will help.

Questions to ask about maintenance

Before you sign, ask how the app will be looked after once it is live:

• Who updates the app when Apple or Google release new versions of their operating systems?
• How are bugs reported and fixed after launch, and how quickly?
• Is there a monthly arrangement, or is support charged as it happens?

FAQ

Is it cheaper to build for iOS or Android first?

With a cross-platform framework, building for both from the start usually costs only a little more than building for one, because most of the code is shared. If you must choose one, pick the platform your target users actually carry.

Why does a "simple" app cost more than expected?

Because simple to use is not the same as simple to build. A single tap that "just works" often hides validation, sync, error handling and an admin view behind it. The simplicity your users feel is something someone had to build.

Can I build my app with no-code tools instead?

Sometimes, and for testing an idea it can be a smart first step. No-code tools get harder once you need custom logic, offline support, complex permissions or full control of your data. Many products start on no-code and move to custom code once the idea is proven.

If you want a realistic picture for your own idea, send me a short brief — what you are building, what already exists and when you need it working — and I will tell you what drives the cost in your case. You can see what I build on the services page.