What does app development cost? An honest look at the price in 2026

The short answer

There is no single price for "an app", in the same way there is no single price for "a house". The price is determined by what the app needs to do, not by a fixed hourly rate. A simple app that shows information and collects a few enquiries is a completely different investment from an app with BankID login, payments, offline support and integrations with specialist systems.

The useful answer is therefore not a number, but an understanding of what drives the price, so you can recognise where your own app lands. That is what this walkthrough is about.

The five things that actually drive the price

1. Scope, number of screens and features. This is the biggest driver. An app with 5 screens costs a fraction of an app with 40. Every feature that has to be designed, built, tested and maintained adds cost. Most apps end up more expensive than necessary because they include too much in version one.

2. Platforms, iOS, Android or both. Should the app exist on both iPhone and Android? With modern frameworks like React Native you share most of the code between the platforms, but it is still more work than one platform alone. A PWA (app in the browser) can cover both at a lower cost, where it fits.

3. Login and security. An open app without login is inexpensive. If you need BankID, ID-porten, Vipps login or roles and permissions, complexity increases, and the requirements for security and privacy follow.

4. Integrations. Should the app talk to an ERP system, a CRM, a payment system or a public register? Each integration is its own small project. This is often where the price, and the risk, sits in larger apps.

5. Backend and data. An app that only shows static content needs little. An app with user accounts, real-time data, notifications and an admin panel needs a proper backend. That is often half the job, even though the user never sees it.

Typical ranges, with caveats

The distinctions below are rough orders of magnitude to give a sense of direction, not a quote. Your app may fall outside these ranges in either direction, and that is exactly why we do a pre-project before giving a price.

Simple MVP, one platform or PWA. A focused first version with a clear core need, a limited number of screens and a simple backend. This is what we recommend most people start with, to get out quickly and learn from real users.

Full-featured app, two platforms, login and some integrations. An app going into production at a company, with user accounts, secure login, a couple of integrations and an admin panel. Most serious B2B and consumer apps land here.

Complex platform, BankID, payments, many integrations, high security requirements. Apps in health, finance or the public sector with strict requirements for privacy, security and uptime. Here the pre-project is extra important, because the details determine much of the cost.

The most important thing to take away: the difference between these levels is not the hourly rate, it is the scope. The cheapest way to reduce cost is almost always to tighten what the app should do in the first version.

Why we give a fixed price

Many development houses bill by the hour. The problem is that it shifts all the risk onto you as the client: you do not know the final sum until the project is finished, and you also pay for the time spent on misunderstandings and rework.

We do the opposite. After a small pre-project where we lock scope, screens and requirements together, we usually give a fixed price. Then you know what you are paying before development begins. Changes along the way are handled as clear additional orders, never as surprises on the final invoice.

The pre-project, the cheapest insurance

A pre-project clarifies what you actually need, what it will cost to build, and what should wait for later versions. It costs a small fraction of the development itself, and you own the result whether or not you continue with us. It is the cheapest way to avoid spending a lot of money on the wrong app.

For most, the smartest path is to start narrow: build a focused first version, get it out to real users, and let their feedback steer what gets built next. That keeps the cost down and the quality up.

In short

• The price is driven by scope, not by an hourly rate.
• The big drivers are features, number of platforms, login/security and integrations.
• The cheapest way to save is to limit what the app should do in version one.
• A fixed price after a pre-project gives you predictability and moves the risk away from you.

Wondering what your particular app will cost? Send us a short description of what you have in mind, and we will give you an honest assessment and a suggested next step. You can also read more about app development with us, or about when a PWA is enough if you want to keep the cost down.