If you want a straight answer to how much does it cost to build an app in 2026, industry benchmarks land in three brackets: a simple app runs $5,000-50,000, a medium one $40,000-120,000, and a complex product $120,000-300,000+. The reason those ranges are so wide is that the number is driven by scope, not by the app idea. Two agencies quoting the same feature list differently are usually not disagreeing about price — they are reading different amounts of work into the same sentences.
What actually sits inside an app development budget
When a founder hands us a feature list, the screens are the visible part. The app development cost is mostly everything attached to those screens that nobody wrote down.
A realistic budget has these line items:
- Discovery. Turning the feature list into a specification: user flows, data model, integrations, edge cases. Skipping discovery does not remove this work, it just moves it into development, where it costs more to redo.
- Design. Screens, states, and the boring ones — empty state, error state, loading, offline. A screen is not one design, it is a set of them.
- Frontend (the app itself). What users touch. Usually the smallest surprise in the estimate.
- Backend. APIs, database, authentication, business logic, jobs, notifications. On most products this is at least as large as the app.
- Admin panel. Someone has to add content, manage users, and read numbers. This is a second interface, and it is regularly forgotten in the first quote.
- QA. Real devices, OS versions, weak networks.
- DevOps and infrastructure. Environments, CI/CD, monitoring, store releases.
- Project management. The coordination that keeps the above from colliding.
The cost of app development is the sum of these, multiplied by an hourly rate. The rate is a regional question — Eastern Europe sits around $40-100/hour, Western Europe $75-200, and the US $100-250. We wrote about that side of the equation separately in mobile app development cost in Europe; this article is about the other multiplier, the volume of work.
What separates a simple app from a medium and a complex one
The tiers are not about how the app looks. They are about how much state the system has to manage and how many things can go wrong.
| Tier | Benchmark range | What it looks like technically |
|---|---|---|
| Simple | $5,000-50,000 | A handful of screens, content mostly read-only, standard login, one or two third-party services, thin or no custom backend, no admin panel beyond a CMS |
| Medium | $40,000-120,000 | Real user accounts and roles, custom backend with meaningful business logic, payments or booking, push notifications, an admin panel, analytics |
| Complex | $120,000-300,000+ | Offline mode, real-time or location features, hardware or device APIs, multiple integrations, traffic spikes, a separate admin product, compliance or legacy migration |
Notice the ranges overlap. A “simple” app with one nasty requirement crosses into medium territory, and a medium app with two of them becomes complex. That overlap is exactly why the average app development cost is a useless planning number on its own — the average includes both a restaurant menu app and a logistics platform.
The practical way to place your product is to count state, not screens. Ask: does data live only on the server, or also on the device? Does anything have to work when the network does not? Does the system have to be correct when two people act at the same time? Every “yes” moves you up a tier.
Which requirements quietly double the number
These are the ones that arrive as a single line in a feature list and land as weeks of engineering:
- “It should work offline.” This is not a caching setting. It is a second data model, a sync protocol, and conflict resolution.
- “Show the user’s location.” Displaying a dot on a map is cheap. Continuous GPS tracking that survives a background app and does not drain the battery is not.
- “It should handle load.” Handling steady traffic is one architecture. Handling a spike concentrated into a few hours is another.
- “Just migrate the old system.” Legacy migration means matching undocumented behaviour, and the old system is the specification.
- “We need a dashboard.” An admin panel with roles, content editing, and reporting is a product with its own backlog.
- “And payments.” Money brings reconciliation, refunds, failure states, and compliance.
None of these change the screen count. All of them change the cost to build an app.
Example from our practice
Questy, built for Fundacja Mapa Pasji, is a clean illustration. It is a city quest app that turns towns into treasure hunts. We built it in React Native as a legacy migration — moving off an older system onto iOS and Android from a single codebase.
The budget was not consumed by screens. It was consumed by three infrastructure requirements:
- Fully offline mode. Quest data is downloaded in advance, progress is written locally, and everything syncs once the network reappears. Players walk through areas with no coverage; the app cannot stop working there.
- Custom GPS tracking. Not a map pin — continuous location tracking balanced between accuracy and battery consumption across routes that run for several hours. Accuracy that drains the phone before the route ends is a failed feature.
- A backend that holds peak load. Traffic is not flat. It concentrates into quest weekends and school trips, when many groups start at once in the same place.
On top of that, a separate admin SaaS for routes, rewards, and statistics — effectively a second product inside the same estimate, with its own design, backend, and release cycle.
If you costed Questy by counting screens, you would land in the simple bracket and be wrong by a wide margin. The mobile app development cost here was set by offline sync, location handling, load behaviour, and the admin product. That is the general lesson: look for the requirements that change the architecture.
What to watch out for
The quote you compare is not the scope you compare. When two agencies give different numbers, read what each one included. One priced the app; the other priced the app, the backend, the admin panel, and QA. Ask both for a line-item breakdown and the gap usually explains itself.
Fixed price hides risk, it does not remove it. A fixed price on a vague specification is priced with a buffer, or it is priced to be renegotiated later. Discovery first, then a fixed price on a defined scope, is the cheaper path.
App store fees are small but real. The Apple Developer Program is $99/year and Google Play is a $25 one-time fee. Trivial next to development, but they are the start of the recurring column, not the end of it.
Infrastructure is a monthly line. Servers, storage, push services, maps, monitoring. It scales with usage, which means your successful launch increases it.
Budget the second version. The first release teaches you what users actually do. If the whole budget goes into v1, there is nothing left to act on what you learn.
Does cross-platform really save money?
Usually yes, and the benchmark saving against two separate native builds is roughly 30-40%. One React Native codebase means one implementation of business logic, one set of screens, one QA pass for the shared behaviour.
Two caveats worth having in the estimate:
- The saving applies to the shared layer. Anything touching the device — background location, permissions, notifications, deep OS integration — still needs platform-specific work and platform-specific testing. In Questy, GPS and background behaviour were exactly where the single codebase stopped being free.
- A single codebase does not halve QA. You still test on both platforms, on real devices, on old OS versions.
Cross-platform is a good default for most products. It is not a good default when the app’s core value is a heavy platform-specific capability.
What keeps costing money after launch
Shipping is the point where spending becomes continuous rather than optional. The benchmark for maintenance is 15-25% of the build cost per year, and it covers OS updates that break things, third-party API changes, security patches, bug fixes, and small improvements. Apps that skip this do not stay still — they degrade, then need a rewrite, which costs more than the maintenance would have.
The pattern repeats across product types. We have written the same breakdown for specific domains in what really drives hotel app costs and in the mobile banking app development cost breakdown — different industries, same conclusion: the budget follows the non-functional requirements.
Conclusion: how much does it cost to build an app
How much does it cost to build an app comes down to two multipliers: the hourly rate of the team you hire and the amount of work your requirements actually contain. The benchmark brackets — $5,000-50,000, $40,000-120,000, $120,000-300,000+ — are useful for orientation, not for planning, because the same feature list can sit in any of them depending on offline behaviour, location handling, peak load, and whether an admin panel is in scope. Cross-platform trims roughly 30-40% off the shared work, and maintenance adds 15-25% of the build cost each year. The most reliable way to get a number you can trust is to run discovery first and let the specification produce the estimate, instead of the other way around. If you want a second opinion on a quote you already have, that is usually a short conversation.
Send us your feature list. We will tell you which requirements sit in the simple bracket, which ones quietly move you into complex, and what a realistic budget looks like for the product you actually described. Start with our product development page, or just write to us — a short call is normally enough to turn a feature list into a scope you can price.
