How Much Does It Cost to Build an App in 2026? Price Bands, Running Costs and the Buy-Instead Maths

Every answer you have read to this question was useless for the same reason: it gave you a range without giving you the arithmetic behind it. "€10,000 to €250,000" is not an estimate, it is a refusal to estimate. So this piece does it the other way round. Here is the model — hours times a rate — here is our actual rate, here are worked examples run through the same calculator this site puts on its own pricing page, and here are the recurring bills that every quote leaves out. Substitute your own rate and the numbers move; the shape does not.

TL;DR:

  • An app costs hours × rate. A quote that gives you a price without an hour count cannot be compared to any other quote.
  • At our published blended rate of €43 an hour, real projects run from about €700 for a single-platform utility to about €7,900 for a SaaS platform across web and mobile.
  • A team charging €100 an hour will quote two to three times those figures for the same scope. Neither is dishonest; the rate is the variable.
  • Running costs can start at $99 a year and genuinely stay near zero until you have users. AI inference is the exception — it has no free floor.
  • The build is the cheapest phase of owning an app. Maintenance, support and acquisition all outlive it.

Table of Contents

The Only Model That Survives Contact With a Real Quote

Software is priced by time. Every other pricing story — per screen, per feature, per platform, fixed-price packages — is that same calculation with the hours hidden, and hiding them is how two quotes for one project end up a factor of five apart with neither party lying.

So there are exactly three questions to ask any studio, and the answers are comparable across all of them:

  1. How many hours? This is scope, and it is the number you can argue with.
  2. At what rate? This is geography and seniority, and it is the number you cannot.
  3. What is excluded? Design, testing, project management, store submission, a server for the thing to talk to — any of these sitting outside the quote changes what the quote means.

We publish both of our numbers, which is unusual enough to be worth stating plainly: €43 an hour, blended across design, engineering, testing, deployment and the calls, with no separate project-management fee because there is no project manager. And 30 productive hours a week — not 40, because nobody writes software for forty hours a week and a timeline built on the pretence slips.

That second figure is how you convert money into a calendar: €43 × 30 is about €1,290 of delivered work per week. A budget of €5,000 is therefore roughly four weeks of a senior engineer's full attention, whatever the feature list says.

Pro Tip: Take any quote you have received, divide it by the studio's stated hourly rate, then divide by 30. If the resulting number of weeks is wildly shorter than the timeline they promised, the rate and the quote do not describe the same project.

Four Worked Examples, With the Hours Shown

These are not illustrative. Each row is the actual output of the estimator behind our cost calculator, for a specific set of answers, at the rate above. The ranges are deliberate — the low end assumes aggressive cuts and no surprises, the high end assumes the full feature set and a couple of integration problems.

What you are building Hours Cost Calendar
A. iPhone-only utility. No accounts, no payments, basic interface. A torch, a converter, a scanner that keeps everything on the device. 19 €700 – €1,000 1–2 weeks
B. iPhone and Android. Email and social login, subscriptions through RevenueCat, a couple of simple integrations, standard design. 48 €1,900 – €2,400 1–2 weeks
C. As B, plus AI features and an admin dashboard to run the thing from. 65 €2,500 – €3,300 2–3 weeks
D. A SaaS platform on web, iPhone and Android. Enterprise single sign-on, Stripe billing, advanced integrations, premium design, AI features, admin dashboard. 155 €6,000 – €7,900 5–6 weeks

Two things in that table are more useful than the prices.

The jump from A to B is a tripling, and it is not about screens. Adding the second platform costs less than doubling, because most of the work is reused. What actually triples the number is the three things B has that A does not: accounts, money, and a server to keep them on. The moment an app has a login, it has password recovery, session handling, a privacy policy with teeth and a support burden. The moment it takes money, it has receipts to validate, states to reconcile and a refund path. Those are not features, they are commitments.

Rushing is a price, not a schedule. Put example C on an urgent timeline and the same 65 hours of work costs €3,200–€4,200 instead of €2,500–€3,300, delivered in 1–2 weeks rather than 2–3. You are not buying speed, you are buying the displacement of other work, and that is what the premium is.

What Actually Drives the Number

In descending order of how much they move an estimate:

  • Accounts. Anonymous apps are dramatically cheaper than apps with users. Enterprise single sign-on is a different order again from an email login.
  • Money. Subscriptions cost more than one-off purchases, and a custom payment flow costs more than either. Using a subscription platform rather than hand-rolling receipt validation is the single highest-leverage cost decision in a mobile app.
  • A back office. "And we need to be able to see the orders" is an admin dashboard, which is a second product with its own screens, roles and permissions.
  • AI features. The integration is not the hard part; the evaluation, the prompt iteration, the failure handling and the per-request cost are.
  • Integrations. Each third-party system is an API you do not control, with its own auth, its own rate limits and its own outages.
  • Design depth. Basic, standard and premium are real multipliers on the whole project, not a line item — custom motion and bespoke components touch every screen.
  • Platforms. Real, but the smallest of these. A second platform adds roughly half again, not double.
  • Store compliance. Invisible in every feature list and present in every project: privacy manifests, data-safety answers, age ratings, screenshots at every required size, and the rejection you did not plan for.

The Routes, and What Each One Costs You Later

We will not invent day rates for other people's businesses, so this table compares the routes on the things that are structural rather than on numbers we would be guessing at. The rate column is the question to ask, not the answer.

Route What sets the price Who owns the code What you carry afterwards Honest risk
Freelancer One person's rate and availability You, if the contract says so — check Everything, the moment they move on Single point of failure, no second opinion
Offshore agency Lowest rate per hour, often most hours You, usually Handover quality varies enormously Communication overhead eats the rate advantage
Small engineer-led studio Mid rate, fewer hours, no layers You A documented codebase, if you asked for one Limited capacity; they can be booked
Large agency Highest rate, plus account management You, after negotiation Process, and a bill for changing your mind Your project may be someone's first
Buy a finished app A fixed price for work already done You, exclusively, if it is sold once A codebase you did not write Fit — it does what it was built to do
Build it yourself with AI tooling Your time, plus tokens You Everything, including the parts you do not understand yet The last 20% is where the cost hides

Pro Tip: The only row where the price is knowable in advance is "buy a finished app", because the work is already done. Every other row is an estimate of something that has not happened yet, which is why they all come with ranges and why the ranges are honest rather than evasive.

The Bills Nobody Quotes

A build quote ends at launch. The app does not. These are the actual recurring line items for a modern React Native app, with current list prices — checked October 2026, and all of them subject to change, so follow the links before you budget on them.

What Free tier Paid from When you start paying
Apple Developer Program None — required to publish $99 / year Immediately, and every year
Google Play developer account None — required to publish $25 one time Once, ever
Backend and database (Supabase) 500 MB database, 5 GB egress, 1 GB files, 50,000 monthly active users, 2 projects Pro from $25 / month When you outgrow the limits — or sooner, because free projects pause after a week of inactivity
Subscriptions (RevenueCat) Up to $2,500 monthly tracked revenue 1% of tracked revenue Only once you are earning, which is the right shape
Crash and error monitoring (Sentry) One user, 5,000 errors, 50 session replays Team from $26 / month When you have a team or real traffic
Builds and over-the-air updates (Expo EAS) 15 iOS and 15 Android builds, updates to 1,000 monthly active users Starter $19 / month; Production $199 / month When you ship often or exceed 1,000 users on updates
AI inference None meaningful Per request From the first user. The only line that scales with usage rather than time
Push notifications (APNs, FCM) Unlimited — Never
Ads (AdMob) No fee — Never — Google takes a share of revenue instead

Read that table twice, because it says something counter-intuitive. A finished app with a few hundred users can genuinely run for $99 a year. The free tiers are not toys; they are designed to carry a product until it has revenue. What breaks that arithmetic is not scale, it is AI: a feature that calls a model on every interaction has a per-user cost from the first user, and it is the one line you must model against your pricing before you ship rather than after.

Store Commission Is a Cost of Revenue, Not of Building

If the app sells anything, the store takes a cut, and it dwarfs everything in the table above. Apple's Small Business Program sets commission at 15% on paid apps and in-app purchases for developers with up to 1 million USD in proceeds in the prior calendar year, and for developers new to the App Store; above that threshold the standard rate applies. Google operates a comparable reduced tier.

Two notes. First, this is a percentage of revenue, so it belongs in your pricing model, not your build budget — but a subscription app at 15% is paying more to the store in its first profitable month than it pays for every service above combined. Second, the fee structures in the EU are genuinely in flux under the Digital Markets Act, including an additional reduced subscription commission under the alternative terms. Anything specific you read about EU fees, here included, needs checking against Apple's current terms rather than trusted.

The Maintenance Floor

An app that gains no features still costs money to keep alive. The floor has three components and none of them are optional:

  • OS releases. iOS and Android ship a major version a year, and each one breaks something — a layout, a permission prompt, a deprecated API.
  • SDK minimum requirements. Apple periodically requires apps to be built against a newer SDK to submit updates at all. Miss one and you cannot ship a bug fix until you have done an upgrade sprint.
  • Store policy. New declarations appear — privacy manifests, data-safety forms, accessibility labels — and apply to apps that already exist.

Budget one or two releases a year for an app in maintenance, and treat anything that has not shipped an update in two years as needing an upgrade sprint before it can ship anything at all. That applies to apps you buy as much as to apps you build, which is why the last update date on a listing is worth as much as the price.

When Buying Finished Is Cheaper, and When It Is Not

A finished, published app with its store listing intact transfers for less than it costs to build the same thing, and the reason is structural rather than generous: the work is done, the review risk has been taken, the listing already has reviews and ranking history, and the seller is holding depleting inventory rather than quoting future labour. Our catalogue sits between €750 and €4,500, which overlaps almost exactly with the build bands above — for the same money you can commission example B, or you can buy something already live that does roughly that.

Buy when something existing does the job and the gap is cosmetic: your brand, your pricing, your market. Buy when time matters — a transfer completes in days, where a build is weeks. Buy when you want the ranking history, which no amount of money reproduces from scratch.

Build when the gap is the product. Bending a bought app towards a materially different idea costs more than starting clean, because you are paying to understand someone else's decisions before you can change them. Build when the data model is wrong for you, when you need a platform the app does not have, or when the thing you are differentiating on is the part that would have to be rewritten.

And if you do buy: read what actually transfers with an App Store listing before you agree a price, because the gap between what buyers assume is included and what Apple actually moves is the most expensive misunderstanding in these deals.

Work Out Your Own Number

The four examples above are four points on a surface with thousands of them. The cost calculator asks nine questions, shows the hours as well as the price, breaks down which answer added what, and will email the result as a PDF if you want something to compare other quotes against. It needs no contact details to show you the range.

If you would rather see something than scope it, the MVP builder takes a sentence and builds a small working app in the browser for €89 — which is the cheapest way to find out whether the idea survives being real.

Sources

Vendor pricing moves. Every figure above was checked in October 2026 and is quoted as a shape rather than a quotation — follow the links before you build a budget on one.

FAQ

How much does it cost to build an app in 2026?

It is a function of hours, and the honest range is wide because the hours are. At our blended rate of €43 an hour, a single-platform utility with no accounts runs about €700–€1,000, a cross-platform app with logins and subscriptions about €1,900–€2,400, the same app with AI features and an admin dashboard about €2,500–€3,300, and a full SaaS platform across web and mobile about €6,000–€7,900. An agency charging €100 an hour will quote two to three times those figures for identical scope. Ask for the hours and the rate separately, and you can compare quotes that otherwise look unrelated.

What are the ongoing costs of running an app?

Publishing costs $99 a year for the Apple Developer Program and a one-time $25 for a Google Play developer account. Beyond that, a small app can genuinely run near zero: Supabase, Sentry and Expo all have free tiers, and RevenueCat charges nothing below $2,500 in monthly tracked revenue. The bills start when you have users — Supabase Pro from $25 a month, Sentry Team from $26, Expo Starter at $19 — and AI inference is the one line with no free floor, because it scales per request rather than per month. Figures checked October 2026.

Is it cheaper to buy an app than to build one?

Usually yes, if something existing is close enough to what you want. A finished, published app with its App Store listing intact transfers for €750–€4,500 in our catalogue, which is less than the build cost of the same thing because the risk has already been taken and the asset is depleting inventory rather than new work. What you are not buying is fit: a bought app does the job it was designed for, and bending it towards a different one can cost more than starting clean. Buy when the gap is cosmetic; build when the gap is the product.

Why do app development quotes vary so much?

Because three different things vary at once and most quotes disclose none of them. The hours depend on scope, which is rarely pinned down at quoting time. The rate depends on where the team is and how senior they are. And the definition of done differs — some quotes include design, testing, store submission and project management, while others treat each as an extra. A quote without an hour count is not comparable to anything. Ask for hours, rate and what is excluded, and three wildly different numbers usually turn out to be two reasonable ones and an outlier.

What hidden costs do app estimates usually miss?

Five, reliably. Store compliance — privacy manifests, data-safety declarations, age ratings and review rejections — which is work regardless of features. Design assets at every required size. The maintenance floor: an app with no new features still needs a release or two a year to survive OS updates and SDK deprecations. Support, which is somebody's actual hours once real users arrive. And acquisition, which is frequently larger than the build and almost never in the quote. The build is the cheapest phase of owning an app.