What Does It Cost to Build an App?
By CodexierPublished 6 min read
Most app quotes are priced on the visible part, the screens, and most app budgets are blown on the invisible part: the backend, the logins, the integrations and the year of upkeep after release. This guide goes through the drivers in the order they usually surprise people, explains why a cross-platform build changes the maths, and uses our fixed packages as a transparent reference. Current prices are on the pricing page.
What an app budget pays for
Think of an app as three products sold as one. The mobile app itself is what the user installs. The backend is a small web service that holds accounts, data and business rules, and it exists whether the quote mentions it or not. The admin side is how you see users, fix data and answer support questions without a developer. Building all three is the job; a quote that prices only the first will be followed by two more.
Backend, logins and integrations
The backend is where most of the hidden cost lives. Every feature that shows data from more than one user, syncs across devices, sends notifications or takes payment needs server logic, a database and an API. Logins add a provider; BankID in particular means a certified identity provider, a test flow and handling for the cases where the user cancels halfway. Each integration with an outside system is priced separately because each has its own authentication, data model and ways of failing.
| Need | Cost effect | Why |
|---|---|---|
| Accounts and profile data | Baseline | Every app needs it; standard components |
| Email or social login | Small | Provider setup and account linking |
| BankID login | Medium | Certified provider, test environment, edge cases |
| Payments or subscriptions | Medium to large | Store billing rules or a payment provider, receipts, refunds |
| Push notifications | Small to medium | Device tokens, a delivery service, permission flows |
| Offline use with sync | Large | Conflict handling and a second data path |
| Integration with a CRM, ERP or Fortnox | Medium per system | Mapping, auth and error handling per system |
| Real-time chat or live location | Large | Different architecture and testing |
Design and testing
Design is cheap to change before code and expensive after. A clickable prototype tested with a handful of real users usually removes two or three screens from the scope and rewrites a flow, which pays for itself before development starts. Testing is the other line that quotes squeeze: an app must be checked on several phone sizes, on both platforms, with poor connectivity and with the permission dialogs users actually see. Ask what devices and cases are covered, and whether a test build will reach you before release.
- Prototype first when the flow is new or the budget is tight; skip it when the app copies a proven pattern.
- Insist on a test build on your own phones through TestFlight and Google Play internal testing before release.
- Accessibility basics such as text scaling, contrast and screen-reader labels are cheap during the build and costly afterwards.
Store release and first-year upkeep
Release is its own small project: developer accounts in your company's name at Apple and Google, screenshots, descriptions, privacy labels, a privacy policy URL, review guidelines to satisfy, and usually one rejection to answer. After release the work does not stop. iOS and Android ship major versions every year, and libraries the app depends on are updated constantly; an app left alone will eventually fail review, crash on new devices or lose a login provider. Budget a maintenance line before you sign the build. Our app maintenance and scaling plan is 14,990 kr per month and covers updates, monitoring and small changes.
| Phase | What it includes | Who pays whom |
|---|---|---|
| Release | Store accounts, listings, review, first submission | Store fees to Apple and Google, release work in the build |
| Months one to three | Crash fixes, first user feedback, small changes | Maintenance plan or hourly |
| Ongoing | OS updates, library upgrades, security, new features | Maintenance plan |
Store developer fees are set by Apple and Google and change; check their current pages rather than any guide.
Our fixed packages as a reference
We price apps as fixed packages because it forces the scope conversation to happen before the build, where it is cheap. The prototype package produces the flows and a clickable prototype you can test and hand to any developer. The MVP app package builds a defined scope for iOS and Android from one codebase, with backend, logins, admin basics and store release included. Anything beyond that scope is quoted as a separate line before work starts, never discovered afterwards.
When you do not need an app: if your users would be just as happy with a mobile-friendly website, that is a fraction of the cost and needs no store review. If the app exists mainly to be on the store, a website with a home-screen shortcut serves the same purpose. If your idea is not validated, a prototype or a landing page comes before any build. The decision rule: build an app when you need the camera, offline use, push notifications, BankID in a native flow, or a presence on the phone that a browser tab cannot give. If none of those apply, we will say so in a free 15-minute call rather than sell you one.
Frequently asked questions
Is a cross-platform app cheaper than two native apps?
Yes, for most business apps. One codebase in React Native or Flutter covers iOS and Android with most of the code shared, which roughly halves the build and the maintenance. Native builds still make sense for apps that depend heavily on device hardware or platform-specific features.
What does an app cost per month after launch?
Hosting for the backend, a few services such as push delivery and crash reporting, store developer fees, and developer time for updates. The developer time is the main line; a maintenance plan makes it predictable, and skipping it is how apps quietly die.
How long does it take to build an app?
A focused MVP app takes weeks once the scope and design are settled; store review adds days to a couple of weeks at the end. Scope changes during the build are what push timelines into months, which is why the prototype phase exists.
Do I need a backend if the app is simple?
If users log in, see each other's data, get notifications or pay, yes. A purely local app such as a calculator or a checklist can run without one. Most business apps need one, and it is better to plan a small backend than to bolt one on later.
Want a fixed price for your app?
Describe what the app must do for its first user and which systems it must talk to. In 15 minutes we place it on the cost drivers above, say whether a prototype or a build comes first, and give you a fixed price.
Book a free 15-minute call