# Mobile App Development Cost: What You Are Really Paying For

> Where mobile app development cost really goes: design, backend, integrations, testing and post-launch fees, plus a simple way to check any quote.

- URL: https://weaveward.com/blog/mobile-app-development-cost
- Published: 2024-07-25
- Updated: 2024-07-25
- Category: Cost & Process
- Tags: mobile app cost, app budgeting, cross-platform, app maintenance, software estimates
- Author: Weaveward Team

Mobile app development cost is mostly the cost of people's time. Any quote you receive is the number of weeks a team needs for design, the app itself, the backend behind it, integrations and testing, multiplied by that team's rate. On top of that come running costs that start the day you launch and never stop.

That is why two quotes for "the same app" can differ by several times: they are rarely pricing the same scope.

This guide breaks a mobile app budget into the parts you are actually paying for, shows which decisions move the number most, and gives you a simple method to sanity-check any estimate before you sign. It also covers the costs after launch, which first-time app owners often forget.

## Where the money goes

Every serious estimate is built from the same blocks, whatever format the vendor uses. If a quote does not show them, ask for them.

| Work block | What it covers | What pushes it up |
|---|---|---|
| Discovery and UX | User roles, flows, wireframes, clickable prototype | Many user types, unclear processes, approvals across departments |
| UI design | Visual design for every screen and state | Custom illustrations, animation, tablet layouts |
| App development | The screens and logic users touch | Screen count, offline mode, camera, maps, real-time updates |
| Backend and database | APIs, business rules, data storage, login | Complex pricing or approval rules, high traffic, audit needs |
| Admin panel | Web dashboard where staff manage products, orders, users | Reports, role permissions, bulk import and export |
| Integrations | Payment gateway, maps, WhatsApp, ERP or accounting | Old systems without APIs, poor documentation |
| Quality assurance | Test cases, device testing, regression testing | Many Android device types, payment flows, security testing |
| Release and management | Store submission, environments, meetings, reporting | Many stakeholders, strict documentation |

Two blocks are routinely underestimated. The backend is invisible in screenshots, yet an app that handles orders, payments or stock often needs as much backend work as screen work. The admin panel is the second: someone in your office has to manage products, refunds and users, and that is a separate web application with its own design and testing.

## The five decisions that move the price most

### 1. Platforms, and how you build for them

Separate native apps in Swift for iOS and Kotlin for Android mean two codebases and usually two developers. A cross-platform framework such as Flutter or React Native lets one codebase serve both, which reduces app-side effort, though not the backend, design or testing. We compare the options in our guide to [native vs cross-platform apps](/blog/native-vs-cross-platform-apps). If most of your customers use Android, launching there first is also a legitimate way to control the first budget.

### 2. How much backend you need

An app that only displays a catalog needs little server work. An app that takes orders, checks stock across outlets, applies promotions and sends status updates needs a real backend with business rules. Backend-as-a-service platforms such as Firebase can shorten early work for simple apps, but complex business logic still has to be written and tested somewhere.

### 3. Integrations

Each integration is a small project: reading the provider's documentation, building, handling failures and testing. Typical ones in Indonesia include a payment gateway that supports QRIS, e-wallets and virtual accounts, WhatsApp or SMS for one-time passwords, maps for delivery addresses, and a link to your accounting or ERP system. Internal systems without an API cost the most, because someone has to build the bridge first.

### 4. Offline, real-time and device features

Features that sound small can be expensive. Offline mode for field staff means local storage and conflict handling when the phone reconnects. Live order tracking needs real-time updates and background location. Barcode scanning, Bluetooth receipt printers and biometric login each add work, plus testing across many Android devices.

### 5. Roles and permissions

An app with one type of user is far simpler than one serving customers, couriers, outlet staff and head office, each with their own screens and rules. Count the roles early, because every new role multiplies the flows to design, build and test.

## How to turn your idea into a planning estimate

You do not need to be technical to produce a first estimate that is good enough for budgeting. The method below mirrors what a careful vendor does internally, and writing it down gives you the start of a [software requirements document](/blog/software-requirements-document-template).

1. **List the user roles:** customer, courier, outlet admin, finance and so on
2. **List the screens per role** and count them: login, home, product list, cart, checkout, order history
3. **List every integration** and every existing system the app must talk to
4. **Mark the hard features:** offline mode, real-time tracking, payments, camera, complex reports
5. **Ask for effort per block in person-weeks,** not just a total price
6. **Multiply by the blended rate and add contingency** for unknowns

Here is the arithmetic for a hypothetical ordering app for a bakery chain with three outlets: a Flutter app for customers, an admin web panel, QRIS and e-wallet payments through a gateway, and WhatsApp order notifications. Every figure is an assumption chosen to illustrate the method, not a quote.

| Block | Assumed effort (person-weeks) |
|---|---|
| Discovery, UX and UI design | 6 |
| Cross-platform customer app | 14 |
| Backend and database | 10 |
| Admin web panel | 6 |
| Integrations (payment, WhatsApp, maps) | 5 |
| Testing and release | 6 |
| Project management | 5 |
| **Total** | **52** |

At an assumed blended rate of IDR 7.5 million per person-week, 52 person-weeks comes to IDR 390 million. A 15 percent contingency brings the planning budget to roughly IDR 450 million. Real rates in Indonesia vary widely with seniority, city and contract type, so treat this purely as a worked example.

The useful part is the sensitivity. Replace the admin panel with a spreadsheet import and drop delivery tracking, and the total falls. Add a courier app and loyalty points, and it rises. Once you can see the blocks, you can decide what belongs in version one; our [MVP guide](/blog/mvp-guide-launch-in-90-days) explains how to choose that first slice.

## Costs that start after launch

The build is only one part of your mobile app development cost, and you pay it once. Running the app is a monthly cost. Budget for these from day one:

| Item | How it is billed | Notes |
|---|---|---|
| Apple Developer Program | USD 99 per year | Required to publish on the App Store |
| Google Play developer account | USD 25, one time | Organization accounts need company verification |
| Servers, database, storage | Monthly, grows with usage | Cloud bills are often in US dollars |
| OTP and notifications | Per SMS or per WhatsApp conversation | Grows with active users |
| Maps and location services | Usage-based beyond a free allowance | Push via Firebase Cloud Messaging is free |
| Store fees on digital goods | 15 to 30 percent of in-app purchases | Physical goods and services can use your own payment gateway |
| Maintenance | Monthly retainer or per release | OS updates, library upgrades, bug fixes |

Maintenance is not optional. Apple and Google ship major OS versions every year, and Google Play requires apps to target a recent Android API level before you can publish updates. Libraries need security patches too. A workable approach is a monthly block of hours with your vendor for fixes and small improvements, with larger features planned as separate projects.

## How to read a quote

Before comparing totals, check that each quote answers the same questions:

- Is effort broken down by block, with assumptions written down?
- Who owns the source code, designs and store accounts? Your company should
- Which devices and OS versions are covered by testing?
- Is the admin panel included, and what exactly can it do?
- What happens after launch: warranty period, response times, monthly cost?
- How are change requests estimated and approved?
- Are third-party fees such as servers, OTP and maps included or separate?

Register the Apple and Google developer accounts under your company, not the vendor's. Both stores ask organizations for a D-U-N-S number, so start that process early. Our checklist on [how to choose a software house](/blog/how-to-choose-a-software-house) covers the vendor questions that matter beyond price.

## FAQ

### Is a cross-platform app always cheaper than two native apps?

Usually on the app side, not always overall. Flutter or React Native lets one team ship a single codebase to Android and iOS, which removes duplicated screen work. Backend, design, testing on both platforms and store releases cost about the same either way. If the app depends heavily on platform-specific hardware features, native development can end up simpler, so decide based on the features you actually need.

### Why do quotes for the same app idea differ so much?

Vendors fill the gaps in a brief with different assumptions. One quote may include an admin panel, automated tests and a year of support, while another covers only the screens in your mockup. Rates also vary with seniority and location. Ask every vendor for effort per block and a written list of assumptions, then compare those lists rather than the totals.

### Can we start with a web app instead of a mobile app?

Often, yes. If users do not need offline use, deep device features or a listing in the app stores, a responsive web app or progressive web app can test demand at lower cost and without store reviews. Many teams launch on the web and add native apps once usage is proven. Our comparison of [progressive web apps and native apps](/blog/progressive-web-apps-vs-native) explains the trade-offs.

### How much should we budget for maintenance each year?

There is no honest single number. Base it on what you expect to happen: yearly OS updates, security patches, small fixes and the features you already know you want. A practical setup is a monthly retainer for a fixed number of hours, reviewed every quarter, plus separate budgets for new features. Ask vendors to state what the retainer covers and how quickly they respond to critical bugs.

### Should we pay for a discovery phase before the full quote?

For anything beyond a simple app, it is usually worth it. A short paid discovery produces user flows, a clickable prototype and an itemized estimate, which lowers the risk of expensive surprises mid-project. You own the outputs, so you can take them to other vendors if you prefer. Keep it time-boxed and agree the deliverables in writing before it starts.

## How Weaveward can build this for you

We would start with a short discovery: map your user roles and screens, confirm the integrations you need, such as a payment gateway with QRIS, WhatsApp notifications and your accounting or ERP system, and turn that into a clickable prototype plus an estimate broken down by block with every assumption written down. The first build milestone would be one working core flow, for example browse, order and pay, delivered to your team through TestFlight and Google Play internal testing so real staff and customers can try it before you commit to the full feature list.

See how we approach [mobile app development](/services/mobile-apps), or [talk to our team](/contact) about your idea and we will help you size it.