Ask five developers what an app costs and you will get five answers spanning two orders of magnitude. That is not evasion — it is because “an app” describes everything from a weekend project to a system with a backend, payments and a support team.

What follows is how the cost is actually built up, so you can estimate your own situation rather than trusting a number from an article that knows nothing about your project.

Who builds it changes everything

This single decision moves the number more than the feature list does, and it is worth understanding what you are actually buying at each level.

Building it yourself costs your time plus the developer account fee and any services you use. If you already have the skills this is by far the cheapest route, and the real cost is the months you are not earning elsewhere.

A freelance developer is the middle option and the most common for a first app. Rates vary enormously by region and experience. You are buying execution, not project management — you still have to know what you want.

A development agency costs several times a freelancer, and the premium buys process rather than code: a project manager, a designer, testing, and someone accountable when it goes wrong. For a business where a failed launch is expensive, that is often worth paying for. For a first personal project, it rarely is.

No-code platforms are the cheapest route to something functional and carry a real ceiling. They suit validating an idea. They suit scaling one badly.

The backend is where budgets break

People estimate apps by counting screens. Screens are the cheap part.

An app that runs entirely on the device — a calculator, a offline tracker, a reference tool — is a fraction of the work of one that needs a server. The moment you add user accounts, everything changes.

• Accounts and login bring password resets, email verification, session handling and account deletion. Account deletion is now an app store requirement, not an optional extra.
• Data sync across devices means conflict resolution, which is genuinely hard to get right.
• Payments bring store billing integration, receipt validation, refunds and subscription state.
• Anything real-time — chat, live updates, notifications — adds infrastructure that also costs money every month.

As a rough guide, adding a backend to an otherwise simple app roughly doubles the build. Adding payments on top adds meaningfully again.

Two platforms is not twice one platform

It is less than double if you use a cross-platform framework, and more than you expect if you build natively twice.

Cross-platform tools let you share most of the code between Android and iOS, which is why most small teams use them. You still pay for platform-specific work — different design conventions, different store requirements, separate testing on both.

For a first app, launching on one platform is usually the right call. Android is cheaper to publish on, since the developer fee is one-off rather than annual, and it dominates most markets outside North America. Ship one, learn whether anyone wants it, then port.

The costs nobody budgets for

This is where first-time app owners get caught, because the quote covers the build and the build is not the whole cost.

• Maintenance. Operating systems update annually and break things. Libraries need updating for security. An app left untouched for two years usually stops working. Budget an ongoing annual percentage of the original build cost, not zero.
• Server and service costs. Hosting, database, notifications, email. Small at low usage and they scale with success.
• Store compliance. Target API level requirements rise every year. Falling behind means your app stops being updatable.
• Support. Someone has to answer emails and reviews. That is a real ongoing time cost.
• Marketing. Frequently larger than the build. An app nobody finds earns nothing regardless of how well it was made.

The last one deserves emphasis. Spending everything on the build and nothing on distribution is the most common way app projects fail — not because the app was bad, but because launching is not the same as being found.

Three rough tiers

Actual prices vary too much by region and by developer to quote responsibly, but the tiers below describe what you are buying at each level. Get quotes for your own project rather than budgeting from any published figure.

Tier one: simple, offline, single platform. A calculator, a habit tracker, a reference tool. No accounts, no server, standard components. Weeks rather than months, and the cheapest thing a competent freelancer builds.

Tier two: accounts, sync, some custom design. Users log in, data follows them across devices, maybe notifications. This is where most real apps sit, and where cost typically multiplies several times over tier one because of everything the backend brings.

Tier three: payments, real-time features, two platforms, bespoke design. A marketplace, a social product, anything with subscriptions and live data. Months of work, ongoing infrastructure costs, and a maintenance commitment that does not end.

Most people describe a tier three app and budget for tier one. That gap is the source of nearly every abandoned app project.

Questions to ask before accepting a quote

• What exactly is included? Design, testing, store submission and the privacy policy are often assumed by the client and excluded by the developer.
• What happens when I change my mind? Every project has changes. Agree the process for pricing them before you need it.
• Who owns the code and the accounts? Get this in writing. The developer account, signing key and source code should all be yours.
• What does maintenance cost after launch? Ask for an annual figure, not a shrug.
• Can I see something you built that is still live? A working app in the store, not a portfolio image.
• What is the plan if it takes longer than estimated? The honest answer tells you a lot about who you are hiring.

A developer who answers these clearly is worth paying more than one who is vague and cheaper. Ambiguity is what gets billed later.

How to make it cost less

• Cut the feature list ruthlessly. Build the one thing the app exists to do and nothing else. Almost every first version contains features nobody ends up using.
• Use standard components. Custom UI is expensive to build and expensive to maintain. Platform defaults are free, familiar and accessible.
• Avoid accounts until you need them. If the app works without login, ship it without login.
• Use managed backend services rather than building infrastructure from scratch.
• Write the specification before hiring. Vague requirements are the single largest cause of overruns, because every unresolved decision becomes a paid conversation.

Frequently asked questions

How long does it take to build an app?

A simple app can be a few weeks. Anything with a backend and payments is typically several months. Add time for store review, and for the mandatory closed testing period if you are on a new personal developer account — our Play Store publishing guide covers that requirement, which catches most people out.

Is it cheaper to hire overseas?

Rates are lower in many regions, and it can work very well. The risks are communication overhead, time zone gaps and difficulty enforcing an agreement across borders. Judge the individual developer rather than the location, and start with a small paid trial task before committing to a full project.

Should I pay a fixed price or hourly?

Fixed price suits a tightly specified project and shifts risk to the developer, who will price that risk in. Hourly suits evolving requirements and shifts risk to you. Fixed price with a clearly defined scope and a written process for changes is usually the safest structure for a first app.

Who owns the code?

Whatever your contract says, so make sure it says something. Get ownership of the source code and all accounts in writing before work starts. Developers holding the signing key or the store account is a genuinely common and genuinely painful problem.

Work out whether it can pay for itself

Before committing to any budget, model what the app might realistically earn. Our app revenue calculator turns daily active users and ad rates into a monthly figure, and the answer is often sobering.

An ad-supported app needs substantial daily usage to produce meaningful income. If your realistic user numbers cannot cover the build within a reasonable period, that is worth knowing before you spend rather than after. We compared the options in ads versus purchases versus subscriptions.

The cheapest app is the one you did not need to build. The second cheapest is the small one you shipped, tested against real users, and expanded only where they asked.