Calcatrice cockatrice logoCalcatrice. Calculate the cost before you commit
Est. 2026
The ledger for
expensive decisions
Menu
All 336 →

Start a Business

How much does it cost to build an app?

Estimate what it costs to build and launch an app, from discovery and design through the build hours, the second platform, the backend, integrations, QA and store setup, plus hosting and the first year of maintenance. See the total, a realistic range, and what each part adds.

§ 01 Your numbers

Change anything. The answer updates as you type.

Count the distinct screens a user can reach, including sign-up, settings and the empty states, not just the ones in your sketch. Screen count is the closest thing to a unit of work in an app quote, which is why cutting the list is the single most effective way to cut the bill.
Engineering hours for one screen end to end: layout, state, the calls it makes, error handling and the tests. A static list screen sits well below this; a screen with a live map, a camera or a payment flow sits well above it. Ask a developer to price two of your real screens before you trust any average, ours included.
The blended hourly rate you are actually quoted. This is the widest variable on the page: an offshore team, a domestic contractor and a city agency can each be a correct answer to the same brief and sit far apart. Use the rate on the quote in front of you rather than a market average.
Count iOS, Android and a web app separately. Launching on one and adding the second after you have users is the usual way to halve the opening bill, and it also means you only rebuild one codebase if the product turns out to be wrong.
What each platform beyond the first adds to the build hours. It is under a full extra build because the design, the backend and the product decisions are already paid for, and it is well above zero even with a cross-platform framework, because store rules, device behaviour and testing are genuinely separate work. Ask your team for their own figure.
Turning an idea into a scope a developer can quote: user flows, a feature list with things deliberately left out, and a technical approach. Teams that skip this pay for it later as change requests, which are the priciest hours on any project.
Wireframes, the interface design for every screen, a small design system so screens stay consistent, plus the icon and store artwork. Design is priced by screens too, so the same cut that shrinks the build shrinks this.
The server side: accounts and authentication, the database, the API the app talks to, an admin view for you, and push notification plumbing. Set this low only if the app genuinely stores everything on the device and talks to nothing.
Payments, social sign-in, maps, analytics, chat, email and anything else you connect. Each one is a separate integration, a separate set of failure cases to handle and often a separate monthly bill of its own.
Test passes across real phones and screen sizes, older OS versions, accessibility checks and the fix cycles that follow. Store review will reject a build for problems your laptop simulator never showed you.
Developer program fees for each store, the privacy policy and data-use declarations both stores now require, the listing copy and screenshots, and the hours spent on resubmission after a first rejection. Budget for at least one rejection.
Servers or a managed backend, the database, file storage, error monitoring and the paid tiers of the services you integrated. Small while you have few users and genuinely growing with them, which is a good problem and still a bill.
How many months of running cost to put on this ledger. Twelve is the honest default, because a year is roughly the interval at which the platforms ship a major OS release and your build has to be updated to keep working.
Paid engineering hours after launch, as a share of what the build cost: OS and SDK updates, store policy changes, bug fixes, dependency upgrades and the small changes the first real users make obvious. This is the line most first-time budgets leave out entirely.
Estimated cost
$70,208

Typical range $28,083 – $154,458

  • Discovery & specification$3,000
  • UX & visual design$6,000
  • Build labour (all platforms)$27,456
  • Backend, API & database$12,000
  • Third-party integrations$3,500
  • QA & device testing$4,500
  • Store accounts & submission$500
  • Hosting & services$3,000
  • Maintenance after launch$10,252
  • Total$70,208
See next steps →

Recommended next steps

Some links below are affiliate links. If you buy through them, Calcatrice may earn a commission at no extra cost to you. We only suggest tools that fit your result, and a company can't pay to show up here.

$25,000 to $120,000 is the common range for a real product: both platforms, accounts and a backend, integrations, a proper QA pass and a year of support. Contract it in phases so you can stop after discovery if the scope moves.

What this assumes, and where it could be wrong

Every one of these is a place the number could be off. They are here because you should be able to check our working, not because we are hedging.

EVERY NUMBER HERE IS YOURS, BECAUSE THERE IS NO PUBLISHED FIGURE TO LOOK UP.
What an app costs is set by the agency or the contractors who quote the hours, the rate their market charges, the number of screens your product actually has and the backend it needs. None of that is a federal statistic, and we would rather itemise our model in front of you than dress it up as a measurement. The defaults on this page are ours and every one of them is editable, so replace them with the figures on your own quotes as they arrive. This page prices building and launching the product and carrying it through its first year. It does not price marketing it, and for many apps getting installed is the larger budget of the two.

The developer rate is the widest variable on this page, and the same brief priced by an offshore team, a domestic contractor and a city agency can come back at figures that look like different projects. Rate alone does not tell you which quote is better value, because a team that needs half the hours at twice the rate lands in the same place with less of your time spent managing it. Compare quotes on hours and scope as well as on the number at the bottom.

Screen count is the lever you actually control. Design and build are both priced roughly per screen, so every screen you move out of version one comes off two lines at once. The screens that break this rule are the ones with a map, a camera, live chat, offline sync or a payment flow, and it is worth asking your developer to price those individually rather than letting them hide inside an average.

An app that ships and is then left alone stops being installable. Both platforms ship a major OS release on roughly an annual cycle and periodically raise the SDK level that a submitted build has to target, so a product with no maintenance budget eventually fails a submission or breaks on new devices. That is why maintenance and hosting sit on the same ledger as the build here instead of in a footnote, and why a quote that covers only the launch is an incomplete answer to the question you asked.

Cross-platform frameworks reduce the second-platform line, they do not remove it. The shared codebase saves much of the screen-by-screen build, while store review rules, permissions, device behaviour, background execution and the testing matrix stay genuinely separate per platform. Set the uplift input to whatever your own team will commit to rather than to zero.

Frequently asked questions

How much does it cost to build an app?
A small single-platform app with a handful of screens and a light backend can land in the low five figures with one contractor, while a two-platform product with accounts, payments and a real backend commonly runs into the high five or low six figures through an agency. Screen count, the developer rate and how much backend you need drive nearly all of the spread. The calculator above builds the number from your own quote rather than from an average.
Why are app development quotes so far apart?
Because the quotes are usually not for the same work. One may assume a single platform, your existing designs and a backend you already run, while another includes discovery, design, both platforms, a backend built from scratch and a year of support. Rate differences between markets sit on top of that. Ask each bidder for hours by phase and an explicit list of what is out of scope, then compare those rather than the totals.
Is it cheaper to launch on one platform first?
Usually yes, and the saving is larger than the money. Launching on one platform cuts the build hours, the testing matrix and the store work, and it means that if the product turns out to be wrong you have only one codebase to change. Set the platforms input to one to see what that opening bill looks like, then add the second once real users have told you the shape of the product.
What does it cost to maintain an app after launch?
Budget a share of the build cost every year, plus the hosting bill. The work is OS and SDK updates, store policy changes, dependency upgrades, bug fixes and the small changes the first real users make obvious. An app left untouched will eventually fail a store submission or break on new devices, so this is a running cost rather than an optional one. The maintenance input above is set as a percentage of the build for that reason.

Related calculators

Business startup costYour numbers

No industry, no benchmark, no data. This one just adds up the numbers you give it.

Open the calculator→
Freelance project quoteYour numbers

A fixed bid is your hourly rate in disguise, plus the revisions and fees people forget to bill. Price those in or eat them.

Open the calculator→