How much does it cost to build an app?

What determines the cost of building an app?

"How much does an app cost?" is about as concrete a question as "how much does a house cost?" A tiny house in a field is a very different thing from a listed canal house, and the same goes for apps. An internal tool for twenty staff is a different beast from a consumer app that has to cope with peak load in the second week after launch. What we can outline are the levers that drive an app's cost: choice of technology, scope, features, design, ongoing maintenance, and how much you contribute to the design yourself.

In our experience, the following factors weigh the heaviest:

• Choice of technology: native, cross-platform, web app or hybrid. Each model has its own cost profile.
• Scope: how many screens, how many user roles and how many use cases the first release needs to cover.
• Custom design vs. component library: the more pixel-perfect and divergent from standard patterns, the more design and build time is required.
• Backend and data: is it just a layer over existing APIs, or does new backend logic and database modelling need to be built as well?
• Integrations: how many external systems need to be connected, such as accounting, CRM, payments, push notifications, identity and analytics.
• Compliance and security: does the app process personal data, payments, medical data or login credentials at enterprise level?
• Maintenance: who keeps it running once version 1 is live in the stores.

We work with fixed sprint budgets and agree a scope per sprint in advance, so you can adjust course at any time. We'd be happy to discuss a detailed breakdown for your specific case in an introductory meeting. For a broader picture of what software development typically costs, you can also read our page on custom software costs, as many of the principles overlap with app budgets.

Native or cross-platform: the biggest cost lever

The first serious decision is almost always the choice of technology. Broadly, there are three flavours: native, cross-platform and mobile web. Each has its strengths.

Native (Swift / Kotlin)

For iOS you build in Swift, and for Android in Kotlin. Two codebases, two disciplines, and either two teams or duplicated expertise. Native gives you the very best performance, full access to platform features and the most refined user experience. The trade-off is that you are effectively building twice. For graphics-heavy, camera or sensor-driven apps, native remains the first choice.

Cross-platform (Flutter, React Native)

A single codebase that delivers both iOS and Android. Flutter (from Google) and React Native (from Meta) are both mature, full-featured frameworks that by 2026 can handle nearly everything a native app can. For most B2B apps, MVPs and consumer apps without heavy graphical workloads, this is the pragmatic choice: one codebase cuts the overall build cost by roughly a third to a half.

Mobile web / progressive web app

A web app that works on a phone, with no store installation required. Cheaper and quicker to launch, but without push notifications on iOS (Apple restricts these heavily), no rich offline mode, and users cannot find it in the app stores. A sound choice for internal tools or B2B portals; rarely the winning route for consumer apps. Also read our guide on build vs buy if you are unsure whether you should build it yourself at all.

iOS, Android or both?

A question we get asked more often than you might think: does the first version really need to be on both platforms? The answer depends on your target audience, not on your preference.

For consumers in the Netherlands, market share is roughly fifty-fifty between Android and iOS, so launching a consumer app on one platform means missing half your market. For business users in the Netherlands, iOS is overrepresented, particularly among executive, sales and marketing roles. For logistics, warehouse and field service, Android dominates because the hardware is cheaper and more robust.

A legitimate strategy is to start with cross-platform and serve both stores at once, which is exactly why Flutter and React Native have become so popular for MVPs. If you want to go native but need to keep the budget in check, you can launch one platform first and decide, based on early user insights, whether a second platform is worth the investment. For app development, we run both routes: we advise based on your target audience, not on what is most technically enjoyable to build.

App types: not every app is an app

"Building an app" is an umbrella term. Under that umbrella sit very different projects with very different price tags. A handful of scenarios we see regularly:

Consumer app (B2C)

For the general public, on both app stores, with onboarding, accounts, push notifications, in-app payments and strict expectations around polish and performance. The most expensive category, because everything has to be right: design, copy, edge cases, App Store review, support for older devices. Here an MVP carries real risk, as a mediocre consumer app receives poor reviews straight away and is hard to rescue.

B2B app for customers or partners

An app for your existing customers or suppliers. Known users, often connected to your existing backend, less dependent on viral onboarding tricks. The business case is usually clear: efficiency, retention, or an extra service layer on top of an existing product. Cross-platform is almost always the right choice.

Internal app for your own staff

For example, a field service app for engineers, an order picking app for warehouses, or a reporting tool for managers. The user group is known and trained, you can specify the hardware yourself, and design requirements are lower. This is almost always the most cost-efficient category. A progressive web app is often good enough here.

MVP / pilot

A deliberately slimmed-down first version to test a hypothesis. Not the same as "a cheap app": an MVP is a learning instrument, not a production system. The value lies in what you learn in the first months, not in what you deliver in week one. This is where we see the most waste: teams building an MVP as if it were a production app, or teams building a production app under the MVP label.

Production app

The mature version. Robust, monitored, tested, scalable, with a release pipeline. It is no coincidence that the step from MVP to production app is often more expensive than the MVP itself: everything you took for granted in the MVP now needs to be properly structured.

Which features drive the budget?

Not every feature costs the same. A handful of categories that in practice have the biggest impact on the budget:

• Real-time functionality: chat, live updates, multi-user editing. Requires websockets or dedicated infrastructure, and considerably more backend work.
• Offline mode: apps that must keep working without a connection and sync later. Data consistency suddenly becomes a serious headache, so expect considerably more testing.
• Custom UI vs. component library: if every screen is uniquely designed and not drawn from a design system, build time rises quickly. A good component library is your best friend when it comes to budget.
• In-app payments: Apple and Google take a 15–30% commission on digital goods sold through their stores. You also need to implement Apple's In-App Purchase API or Google Play Billing, including restores, refunds and family sharing edge cases.
• Push notifications: basic push is inexpensive, but targeted segmentation with rich content and deep linking is a project in its own right.
• Camera, scanner, sensors: QR code scanning is nearly free, but product photo recognition using machine learning classification is a serious undertaking.
• Integrations: every external API you connect costs design, build, error handling and monitoring. Read what an API integration involves if you want to go deeper.
• Authentication: simple email and password is inexpensive. Single sign-on with Microsoft, Google, Apple or an enterprise identity provider is a significant extension.
• Location and maps: standard maps are affordable, but routing, geofencing and maps with many custom layers quickly become expensive, both to build and in monthly map tile costs.
• Backend APIs: if the app is a front end over an existing system that already has a good API, you save a lot of work. If new backend logic needs building, that becomes a separate project in its own right.

A useful rule of thumb: cross off every feature you're not certain must be in version one. Version two is a better home for borderline cases, provided you keep them within reach.

Hidden costs people run into

Build costs are often only half the story. What you continue to spend on an app after launch is consistently underestimated. The main items are:

App store accounts

An Apple Developer account costs a fixed annual fee. For Google Play Developer, you pay a one-off registration fee. It sounds small, but nothing happens without these accounts, and the Apple renewal process has more than once gone wrong.

App Store review process

Every release must pass Apple's review team. This usually takes a few days, though a release can sometimes be rejected under Apple's Human Interface Guidelines or payment rules. That is not a cost in euros but it is a cost in time, and if your release fixes something that is broken in production, every day of waiting feels very long.

Releases per year

An app is never truly "finished". Every release requires design, build, testing and the full review process all over again. Plan for a few major releases a year plus smaller fixes. Apps that never receive updates eventually drop out of the market, and users can see that in the release history.

OS updates and device fragmentation

Apple releases a new iOS every autumn, and Android follows its own schedule. Occasionally such an update breaks something in your app. Keeping compatibility with the latest two iOS and Android versions is part of ongoing maintenance. On Android, there is also the variety of devices, screen sizes and manufacturer-specific ROM modifications to contend with.

Security updates and library maintenance

Mobile apps use dozens of open-source libraries, and there is almost always a security patch somewhere among them each month. If you don't keep up with them, after a few years you end up with an app that only someone with a great deal of patience can update.

Backend hosting and SaaS licences

The backend runs somewhere, and cloud hosting costs money every month. Push providers, error tracking (Sentry or Bugsnag), analytics (Mixpanel or Amplitude), authentication (Auth0 or Cognito), maps (Mapbox or Google) and email (Postmark or SendGrid): each of these services is affordable on its own, but the costs add up.

App Store and Play Store commission

If you sell in-app purchases, 15–30% goes to Apple or Google. For SaaS businesses, this is a significant cost to factor into your pricing model.

MVP versus production app: the real trade-off

Many teams struggle with the choice between "getting something to market quickly" and "doing it properly from the start". Both positions have merit, but the choice has a major impact on budget and on the success of the project.

A good MVP is a product with just enough functionality to test the core hypothesis. It is not a demo or a clickable prototype, but nor is it a production app. The value of an MVP lies in what you learn: will real users actually do what they promised to do? Is the pricing model right? Where do people drop off? You can only answer those questions with software that people can actually use.

A production app has a different purpose: to work at scale, over the long term, in a market you already understand. Here, matters such as observability, automated testing, error handling, release processes and compliance need to be right from day one. Building a production app at MVP scale is more expensive and delivers less than the two approaches kept separate.

The dangerous middle ground: a team that promises an MVP but in practice builds a production app without the accompanying quality layer. That is the worst of both worlds: more expensive than a genuine MVP, more fragile than a genuine production app. In the first session, we explicitly discuss which of the two you need, and steer accordingly.

What determines a mobile developer's hourly rate?

An hourly rate says little until you know what you get for it. Three factors matter most:

• Seniority and experience: a senior iOS engineer who has hundreds of apps live in the stores delivers more in less time than a junior still climbing the learning curve. The hourly rate differs considerably, but the total budget is often lower than you might expect, because seniors do less rework.
• Specialisation: general app developers are scarcer than web developers and therefore more expensive. Specialist niches (AR/VR, complex Bluetooth/BLE, low-level audio processing) have their own rate levels.
• Location and model: Dutch agencies have higher rates than offshore teams. The question is what you get in return in terms of communication, time zone, legal safeguards and quality, and that trade-off differs from project to project.

We are a Dutch development partner with a fixed team and work with sprint budgets. There is a transparent hourly rate behind that, but you steer on sprint output: at the end of each sprint you receive working functionality, not a timesheet. For larger or business-critical projects, you can also look at our page on building enterprise software.

And what about no-code platforms such as FlutterFlow and Glide?

To be candid: no-code and low-code mobile platforms such as FlutterFlow, Glide, Bubble (web) and Adalo have become considerably more mature in recent years. They are a legitimate choice in a number of scenarios, but certainly not for everything.

Where no-code works well: proofs of concept, internal tools for a handful of users, standardised flows (forms, dashboards, simple CRUD apps), or validating an idea before committing development budget to it. We have seen clients get a first internal tool up and running with FlutterFlow in a few weeks, which would otherwise have taken months.

Where no-code falls short: when the app becomes a structural part of your business, as complexity grows, under rigid compliance requirements, with large user numbers, where rich offline capability is needed, or where integrations fall outside the platform's standard offering. Vendor lock-in is a serious issue: you can scarcely migrate to your own codebase without considerable pain.

Our pragmatic line: use no-code for what it is, a quick, affordable way to put something in the market and learn. But agree in advance that, should the app take off and become serious, you will lay the foundations again with proper software. That is not failure; it is a normal lifecycle.

Frequently asked questions about app costs

Which is cheaper: native or cross-platform?

Cross-platform is in almost all scenarios cheaper if you want to serve both platforms — you maintain one codebase instead of two. Native only wins on cost if you target a single platform exclusively, or if your app relies heavily on platform-specific features that Flutter or React Native cannot handle well.

Should I start with an MVP or build a production app straight away?

That depends on how confident you are in your hypothesis. If you don't yet know whether people will use it, build an MVP and accept that it will be limited and rough. If you already have evidence that the need exists — for example, because you can see people using ad hoc workarounds today — you can consider a streamlined production app straight away. The dangerous middle ground is building an "MVP" as if it were production.

How long does it take to build an app?

For a simple cross-platform app we're talking about a few sprints; a consumer production app is a project spanning several sprints. But the timeline depends less on the technology than on how sharp your scope is and how quickly you can make decisions along the way. In our experience, projects overrun more often because of decision-making than because of the build itself.

What do I need for the App Store and Google Play?

You need an Apple Developer Account and a Google Play Developer Account — these are opened in your own company name, not your agency's. We guide the initial publication, including writing store listings, screenshots and handling the review process, but you remain the legal owner of the apps in the stores. This is important for exit scenarios.

Can we keep making updates once the app is live?

Yes, and we recommend it. Apps that sit untouched for months perform poorly in the stores and lose users. We work in ongoing sprint cycles in which we add functionality, apply security updates and keep the app aligned with new iOS and Android versions. You can also take this over in-house once your team has got to grips with the codebase — we are happy to document everything and run handover sessions.

Can we start with a no-code platform and switch later?

Technically it's possible, but don't underestimate the migration. No-code apps have their own data models, their own flows and their own place where the business logic lives. A genuine rebuild is almost always necessary — what you mainly take with you are the validated requirements, not the code. That's not a problem in itself, as long as you build that moment into your planning in advance.