The cost of a mobile app is driven mainly by its scope: how many types of users it serves, how many screens and flows each of them goes through, which platforms it ships on, and what kind of backend and admin panel sit behind it. On top of that come integrations such as payments, maps, SMS and push notifications, plus design, testing, app store accounts and maintenance after launch. Instead of quoting prices, this article explains those items and how to prepare for an accurate quote.
User roles, screens and flows
The quickest way to size an app is to count who will use it. Ordering, delivery and booking platforms usually involve more than one party: the customer who buys, the business that prepares the order, the courier who delivers it. Each role has its own sign-in flow, permissions, notifications and screens, and each role often means a separate app or panel.
Two examples from our projects: ÇAK combines a customer app, a business app called ÇAK İşletme and a website. ANTLY consists of two apps that match businesses’ delivery requests with couriers: ANTLY Kurye (courier) and ANTLY İşletme (business). More roles do not only mean more screens; they also mean more interaction between roles. The status of an order has to be correct on the customer’s, the business’s and the courier’s screen at the same time.
Counting flows gives a more realistic picture than counting screens. “Sign up, pick a product, pay, track the order” is a single flow, but behind it sit easily forgotten screens: empty lists, error messages, lost connections and permission prompts. Store rules add scope too. If your app lets people create an account, both the App Store Review Guidelines (5.1.1(v)) and Google Play’s account deletion requirements require a way to delete that account from inside the app. Google Play also asks for a web link where users can request deletion outside the app.
Platforms, backend and admin panel
Building two separate native apps for iOS and Android means two codebases, two rounds of development and two rounds of maintenance. We usually build both platforms from one codebase with React Native and add platform-specific modules when needed. We compare the trade-offs in React Native vs Flutter vs native.
If the web is also a target, scope grows. Decide early whether you need a web app where users can do things in the browser, or a site that introduces the product and links to the stores. Extra stores count as well: ÇAK’s customer and business apps, for example, were published on Huawei AppGallery in addition to the App Store and Google Play. Every store brings its own release and update process.
The invisible half of an app is the backend. User accounts, orders and payments live on a server, in a database and behind an API the apps talk to. You also need an admin panel where you approve users, edit content, follow orders and pull reports. That panel can take as much work as the app your users see, so when you compare quotes, check whether it is in scope and which reports it includes.
Integrations and usage-based costs
Every integration has two costs: the work to build and test it, and the usage fee the provider charges once you are live. The second never appears in a development quote, yet grows with your user base.
| Integration | Development work | After launch |
|---|---|---|
| Payments and wallet | Checkout flow, refunds, balance, payment provider onboarding | Commission per transaction |
| Maps and location | Address picker, live location, distance and routing | Fee based on number of requests |
| SMS one-time passwords | Sign-in flow, resend, abuse limits | Fee per SMS sent |
| Push notifications | Notification types, permission prompts, iOS and Android setup | Depends on the service you choose |
A few examples as of October 2026: iyzico, a Turkish payment provider, states on its pricing page (in Turkish) that it charges no setup fee and takes a percentage plus a fixed fee on successful transactions. Google Maps Platform bills per request and includes a monthly number of free requests for each product. Firebase bills phone authentication per SMS sent, while the same page lists Cloud Messaging for push notifications as no-cost.
There is one store rule to know before you design payments. Under the App Store Review Guidelines, unlocking features or digital content inside an app must go through Apple’s in-app purchase (3.1.1). Physical goods and services consumed outside the app must use a payment method other than in-app purchase (3.1.3(e)). ÇAK falls into the second group: users buy with an in-app wallet powered by iyzico, collect the product from the business with a delivery code, and sign in with a one-time password sent to their phone. Which group your revenue model falls into shapes the payment integration from day one.
Design, testing and app store release
The design phase covers user flows, the interface and a clickable prototype you can try before any code is written. Changing a flow in a prototype is far cheaper than changing it in code, so time spent on design usually lowers the total cost.
Testing means running every role’s flows end to end on different screen sizes and operating system versions. Before launch you also use the stores’ beta tools: on Apple’s side, TestFlight is included in the Apple Developer Program. On Google Play, personal developer accounts created after November 13, 2023 must run a closed test with at least 12 testers who stay opted in for 14 consecutive days before the app can go live.
App store accounts (October 2026)
- Apple Developer Program: 99 USD per year, charged in local currency where available (Apple).
- Google Play developer account: a one-time registration fee of 25 USD (Play Console Help).
- Organization accounts: Both Apple and Google Play require a D-U-N-S Number, a nine-digit business identifier issued by Dun & Bradstreet. Apple notes it is free in most jurisdictions.
We recommend opening these accounts in your company’s name rather than your developer’s. The app, its reviews and its user history are your asset. Getting a D-U-N-S Number and verifying the accounts can take time, so start early.
After launch: hosting and maintenance
Costs do not stop at launch. Servers, the database, file storage and backups are monthly expenses that grow with your user count. The usage fees of the integrations above belong in this line as well.
The least understood reason for maintenance is operating system and store requirements. Even if you never add a feature, the stores expect your app to be built with current tools:
- Google Play: From August 31, 2026, new apps and app updates must target Android 16 (API level 36). Existing apps that target below Android 15 (API level 35) are no longer shown to new users on newer Android versions (Android Developers).
- App Store: Since April 28, 2026, apps uploaded to App Store Connect must be built with Xcode 26 or later using the iOS 26 SDK (Apple Developer).
Raising the target version is rarely a single setting. Libraries need updating, and permission and notification behaviour has to be tested again. That is why we suggest seeing maintenance as a separate line in any quote and planning at least one compatibility update every year.
Start with an MVP and come prepared
Why an MVP?
An MVP (minimum viable product) is a first version that runs the most important flow end to end. Instead of building every feature at once, we recommend launching with that version and adding features based on real user data. Your first investment is smaller, and you do not spend budget on features nobody uses.
Scope usually shrinks fastest at the role level. On a three-sided delivery platform, for example, serving businesses through a web panel instead of a mobile app in the first version can noticeably reduce the initial cost. Loyalty programmes, campaign tools, advanced reports and extra languages can often wait for version two.
What to bring to the first meeting
A quote is only as accurate as the information behind it. This list is enough to start:
- User roles: Who will use the app, and what does each role do?
- Core flows: A few sentences each, or rough sketches on paper.
- Platforms: iOS, Android, web; do you need Huawei AppGallery?
- Integrations: Payments, maps, SMS, notifications, plus any ERP, inventory or accounting system you already use and the providers you have contracts with.
- Reference apps: A few similar apps, with what you like and dislike about them.
- MVP boundary: Must-have features versus those that can wait.
- Timeline and brand: Target launch date, logo and brand colours.
- Accounts: Do you already have store accounts and a D-U-N-S Number?
We don’t sell fixed packages; after the first meeting we send a written, itemised quote. Itemised quotes are also easier to compare.
Conclusion
A mobile app’s cost comes from its user roles, flows, platforms, backend and admin panel, integrations and maintenance, while app store fees are fixed amounts you can know in advance. Narrowing the scope with an MVP and discussing each item separately makes both the budget and the timeline more predictable. If you like, we can break your idea down into items together: see how we work on our web and mobile app development page, or reach us through the contact page.
