Mobile App Development Cost: What Drives the Price, With Real Numbers

Most mobile app quotes come down to one multiplication: the months of work the app needs, times what a month of that team's time costs. With our team in Turkey, an entry-level app comes to roughly 250,000 to 1,000,000 TL as of October 2026 (about $5,000 to $20,000), and our rule of thumb is about 250,000 TL per month of development. Where the team sits sets the monthly rate. Your scope, and how much already exists behind the app, sets the number of months.

The formula behind every quote

Vendors price in different units: hourly, daily, per sprint or a fixed total. Underneath, each of them is estimating the same thing, which is how many people will work for how many months. A fixed price is that estimate with a margin for risk added on top.

That is why comparing hourly rates on their own misleads. A cheaper team that needs twice the hours costs more, and you usually find out halfway through the project.

Location moves the monthly rate a long way. For scale, the median annual wage for software developers in the US was $135,980 in May 2025. That is about $11,300 a month in salary for one person, before payroll taxes, benefits, management or any agency margin. Our 250,000 TL rule of thumb for a month of development is about $5,000 or €4,500 at the Central Bank of the Republic of Türkiye's indicative rate for 16 October 2026 (1 USD = 49.36 TL, 1 EUR = 55.52 TL). TL prices age quickly with Turkish inflation, so read these as October 2026 figures.

The months are the side you can control. At our monthly rate, the entry-level range works out to one to four months of work: a focused first version with a small set of core features. Most of what stretches those months is predictable, and it is the same in Ankara, Berlin or Austin.

What adds months

Scope: count roles and flows, not screens

Screens are a poor unit. A login screen and a checkout screen are one screen each, yet checkout can take a week once you handle declined cards, receipts and refunds. A better unit is the flow: everything a user does to reach one outcome, such as signing up, booking a slot or getting a refund.

Then count the roles. A booking app where customers book, service providers manage their calendars and an operator approves new providers is three products sharing one database. The operator side is usually a web admin panel, and it is the easiest part to forget when you ask for a quote.

Platforms: one codebase or two

Native apps (Swift for iOS, Kotlin for Android) mean two codebases and two rounds of UI work. Cross-platform frameworks such as React Native and Flutter share most of the code between both. For business apps (bookings, catalogs, field forms, dashboards, marketplaces) we start cross-platform; our Flutter write-up covers where that holds and where it strains. We would go native when the app lives on the hardware: heavy Bluetooth work, AR, advanced camera processing or long-running background tasks.

You also don't need both stores on day one. The iPhone and Android split varies a lot by country, and for an internal company app it is decided by the phones the company hands out. Launch where your users are, and add the second store once the first has proved the app.

The backend: where the biggest swings come from

The app on the phone is the visible part. Behind it sit user accounts, a database, an API, file storage, push notifications, an admin panel and background jobs that send emails or sync data. If those already exist because you run a web product, the mobile app is a new front end and a much smaller project. If they don't, building them can easily take longer than the app itself.

Managed backends such as Supabase or Firebase give you accounts, a database and file storage ready to use. For a first version they are usually the right call, and you can move parts to your own services later if you outgrow them.

Integrations: each one is a small project

Payments, maps, SMS verification, social login, a shipping carrier, your ERP or CRM: each integration brings someone else's API, a sandbox account, credentials, edge cases and failure handling. Ask for every integration to be estimated as its own line, because that is where unplanned weeks hide.

Payments come with a rule that changes the economics. If you sell digital content or features inside the app (subscriptions, premium features, in-game currency), Apple requires its in-app purchase system in most markets and takes a commission. If you sell physical goods or services used outside the app, such as a meal delivery, a haircut or a parcel, Apple's App Review Guidelines require you to use other payment methods (rules 3.1.1 and 3.1.3(e)). You then integrate an ordinary payment provider, pay its processing fee, and the store takes nothing. Google Play draws the same line.

Design

Standard platform components in your colors are cheap. A custom design system with bespoke components and animations means design work before development starts, then more development time to build it. For a first version we would spend the design budget on making the core flow obvious and leave the custom look for later.

Store rules and compliance

A few costs never appear on a feature list, but every app pays them:

• If users can create an account, Apple requires that they can also delete it from inside the app (rule 5.1.1(v)).
• Apple's minimum functionality rule (4.2) expects more than a repackaged website, so a thin web wrapper risks rejection.
• Publish under your company. Apple and Google both ask organizations for a D-U-N-S number. It is free, but Apple warns it can take up to five business days to arrive, so request it well before the app is finished. On Google Play, personal accounts created after 13 November 2023 must run a closed test with at least 12 testers for 14 consecutive days before going live; organization accounts skip that step.
• Privacy law (GDPR in Europe, KVKK in Turkey) and sector rules in health or finance add consent screens, data export and deletion, audit logs and sometimes limits on where data can be hosted.

Two of our apps: one month and six months

For a Finnish property-search platform whose name we keep private, we built the iOS app with Expo and React Native in about a month, working with AI coding tools, and it passed App Store review in October 2026. The platform behind it was already running: crawlers that collect listings, a Supabase database, and search and maps on the Next.js website. The app was a new front end on a working product.

For My3PL, a warehouse directory, a team of two to five of us built the website, the web app and a Flutter mobile app together. That took about six months, starting in 2022, before AI coding tools were part of how we worked. Nothing was in place yet, so the backend, the data model and the web product were all part of the job.

Two things separate these projects, and we can't cleanly split one from the other. AI-assisted development made the coding faster, and the Finnish app had a finished backend under it. What we take from it: if you already have a web product with an API, expect the app to be a much smaller project than the platform behind it. If you are starting from nothing, budget for the backend as a project of its own.

What the app keeps costing after launch

Building is a one-off. These costs continue:

• The Apple Developer Program costs $99 a year, and Google Play charges a one-time $25 registration fee.
• Digital sales inside the app carry a commission. Apple takes 15% from developers enrolled in its Small Business Program (up to $1 million in yearly proceeds) and 30% otherwise, with different terms in the EU and some other markets. Google moved to a new fee structure in the US, UK and EEA on 30 June 2026 and in Australia and Japan on 30 September. In the US, UK and EEA, auto-renewing subscriptions now carry a 10% service fee plus a 5% billing fee when the purchase goes through Google Play's own billing; other purchases depend on your yearly earnings and on when the user installed the app. Everywhere else, until the new structure arrives, it takes 15% on the first $1 million of yearly earnings, 30% above that, and 15% on auto-renewing subscriptions. Check the rate card for each country you sell in.
• Hosting and third-party services cover the backend, file storage, maps, SMS, email and crash reporting. Small apps often fit in free or entry tiers, and the bill grows with your users.
• Apple and Google raise their requirements every year. Since 28 April 2026, apps uploaded to App Store Connect must be built with Xcode 26 and the iOS 26 SDK. From 31 August 2026, new Android apps and updates must target Android 16 (API level 36), and existing apps that target Android 14 or lower stop showing up for new users on newer Android versions.

That last point is the one people underestimate. An app nobody touches for a year needs an upgrade pass before you can ship even a one-line fix, so ask for maintenance as its own line in the quote.

How to get quotes you can compare

Before you ask anyone for a price, write one page that covers:

1. Who uses the app (the roles) and the three to five things each role must be able to do.
2. What exists already: a website, an API, a database, a CRM or ERP.
3. Which platforms you need at launch and which can wait.
4. Every integration, by name.
5. What you sell in the app, if anything, and whether it is digital or physical.
6. Any data rules you fall under: health, finance, children's data, personal data.

Then ask every vendor the same questions. Are the backend and admin panel included, or assumed to exist? Does the price cover design, testing on real devices and store submission? In whose name will the store accounts and the source code be? What does maintenance cost after launch, and who handles the yearly SDK updates? Is VAT included? A quote far below the others usually answers one of those differently.

Cutting the first version down to one core flow is the most reliable way to lower the price, and our MVP development guide covers how to pick that flow. On contract type, a fixed price works for a small first version with a written scope. For anything larger we prefer short paid milestones that each end in a build you can install, so nobody is betting on a guess made before the problem was understood. For the steps between the brief and the store listing, see our mobile app development process.

Frequently asked questions

How long does it take to build a mobile app?

At our rates, an entry-level app is one to four months of work. Our iOS app for the Finnish platform took about a month, built on a backend that already existed and with AI coding tools. For My3PL, a website, web app and mobile app built from scratch took about six months, before we used those tools.

Should I build for iPhone or Android first?

Build cross-platform and release first on the platform most of your users carry. Check the split in your country, and for a company app, ask which phones the company issues.

Can I just turn my website into an app?

You can wrap a site in an app shell, but Apple rejects apps that are little more than a repackaged website. If your site already works well on phones and you mainly want an icon on the home screen, a progressive web app may be enough. Build a real app when you need device features, offline use or a place in the stores.

Do Apple and Google take a cut of every sale?

Only of digital goods and features sold inside the app. Physical goods and real-world services go through your own payment provider, and a free or ad-funded app pays only the developer account fees.

If you want a number for your own app, send that one-page brief through our mobile app development page and we will tell you how many months we think it needs.