How much does it cost to build an app?

What an app costs to build depends first on what kind of app you need. There are three ways to put your service on a phone, and they differ in price, in what they can do and in how much upkeep they need.

• Web app or PWA (progressive web app): a website that behaves like an app. It runs in the browser on every device, can be added to the home screen and can send notifications, but it is not in the App Store or Google Play.
• Cross-platform app: one codebase, written with a framework such as Flutter, React Native or Kotlin Multiplatform, that produces both an iPhone and an Android app.
• Native apps: a separate app per platform, written in Swift for iPhone and in Kotlin, Google's preferred language, for Android. The most direct access to the phone and to new system features on the day they ship, at the cost of two codebases.

Native is not always better, and cross-platform is not always cheaper. Cross-platform saves the most when both apps look and behave the same and consist mostly of screens, forms and data. Native pays off when the app leans on Bluetooth, background location, widgets, a watch app or smooth graphics, or when only one platform matters to your customers.

A web app can also be the first step, and our guide to what a web application costs prices that route. It tests the idea with real users for less money, and when the stores or the hardware become necessary, the backend and the design carry over. A website wrapped in a thin app shell is not a shortcut, though: Apple's review guidelines reject apps that are little more than a repackaged website.

Two apps with the same number of screens can differ in price several times over. The difference is in what happens behind the screens: who logs in, what data moves where, and which other systems the app talks to.

1. 1

   Screens and flows

   Every screen is designed, built and tested on small and large phones. A flow such as sign-up, checkout or booking crosses several screens and must handle every error along the way.

2. 2

   Accounts and roles

   Login brings password resets, email checks and, on the App Store, a way to delete the account inside the app. Each extra role, such as customer, staff or admin, adds its own screens and rules.

3. 3

   Data and a backend

   Once data must sync across devices or users, the app needs a server with a database and an interface for the app to call. That is often half the work. A content-only app needs far less.

4. 4

   Payments

   Physical goods and services are paid through a payment provider such as Mollie or Stripe. Digital content sold inside the app usually goes through Apple's and Google's own billing, with their commission.

5. 5

   Integrations

   Links to your booking system, CRM, accounting software or another supplier's API. Each one costs more when its documentation is thin or it has no test environment.

6. 6

   Admin panel and design depth

   Someone has to manage content, users and orders, usually in a web dashboard. And a custom design with its own animations costs more than a clean one built on each platform's standard components.

The cheapest feature is the one you leave out of the first version. Everything above can be added later, and an app that launches small learns from real users before you spend on the rest.

These are our indicative ranges for a first version on iPhone and Android, excluding VAT. Your quote is a fixed price for an agreed scope, so the range becomes one number before any work starts.

For comparison, this is what four other agencies in the Netherlands and Germany publish. Their ranges are higher than ours in every tier. Definitions differ too: some count a user role or an integration as part of a simple app, which would sit in our second tier.

Whichever quotes you compare, check that each one covers the backend, the admin panel, testing on real devices and getting through store review before you compare totals. Weighing an app against selling online? Our guide to what a webshop costs runs the same numbers for an online store.

Putting an app in the stores costs little: Apple's developer program costs 99 US dollars a year, charged in local currency, and Google Play asks a one-off 25 dollars. The real running costs are elsewhere. An app depends on two operating systems that change every year, and on a backend that must stay online and secure.

Maintenance is the line people forget. Since 28 April 2026, Apple only accepts app updates built with the iOS 26 tools, and since 31 August 2026, Google Play requires new apps and updates to target Android 16. Every year brings new deadlines like these, so an app nobody maintains cannot ship even a small fix, and on Google Play it gradually stops reaching new users on newer phones.

In these examples, three years of running costs add 70 to 90% to the build price. Budget for them from the start, and ask every agency what its maintenance covers and costs per year. Websites follow the same logic; our guide to website maintenance costs breaks those down item by item.

Tools such as Lovable and Bolt build a working app from a written description in minutes, for a monthly subscription. That is a real change, and for some jobs they are the right choice.

They are good at the first step: a clickable prototype to test an idea with customers, a demo for investors, or a small internal tool for a few colleagues. A working prototype also makes any later quote more accurate, because everyone looks at the same thing.

They stop where an app becomes a business system:

• Security. The tool writes the code, but nobody reviews it. In 2025 a flaw was recorded (CVE-2025-48757) in which weak database access rules let outsiders read and change data in apps built with Lovable. Lovable disputes it, saying each customer is responsible for their own app's data, which is exactly the point.
• Store apps. Lovable builds web apps only. Bolt can generate mobile app code through Expo, but store accounts, signing, review and privacy labels remain your job.
• Data ownership. You can usually export the code, but check where the database runs, whether you can move it, and what happens to your data when you stop paying.
• Maintenance. An app built by prompts still needs the yearly iOS and Android updates. Prompting changes into a large codebase tends to break other parts, and someone has to understand the code to fix them.

A sensible path for many businesses: prototype with an AI builder, test it with real users, then have the version you launch built properly, with the prototype as the specification. What you pay a studio for is not the typing. It is the design decisions, the review, the testing and someone who answers when it breaks.

The more precise your question, the narrower the quote. You do not need a technical specification. You need to know who uses the app and what they must be able to do with it.

1. 1

   Describe the users

   Customers, staff or both? Which phones do they carry, and how do they find you today?

2. 2

   Write user stories

   One sentence per task: "As a customer, I want to move my appointment, so I don't have to call." Ten to thirty of these describe most first versions.

3. 3

   Split must-have from nice-to-have

   Mark what the first version cannot launch without. Everything else goes on a list for version two.

4. 4

   Collect examples

   Screenshots of apps you like, and of what annoys you in them. Examples settle design questions faster than descriptions.

5. 5

   List your systems

   Booking software, webshop, CRM, accounting: everything the app must talk to, with a contact at each supplier.

6. 6

   Name the deadline and the budget

   A trade fair, a season or a funding round. A budget range lets a studio propose what fits instead of guessing.

With that in hand, ask each studio for a fixed price for the same scope, and compare what is included: design, backend, admin panel, testing on real devices, store submission and support after launch. Our pricing page shows how we price fixed scopes, and Web & app development shows what we build. Ask who owns the code, too: with us, you do once the invoices are paid, as set out under ownership in our terms.

Want a second pair of eyes on your plan? Describe your app idea and we help you sharpen the scope, then send a fixed price and a timeline.