Mobile app development cost: a line-item model and a quote comparison template

Six factors that drive the cost

Mobile app development cost is not one number but a list of line items, and the share of each depends on the project. Six factors decide which lines of the list grow and which shrink. The price table on our mobile app development page summarizes the factors; here we look inside each one.

1. Number of screens and flows, but more so the number of states. A screen is not one piece of work: the same screen has empty, loading, error, unauthorized and offline states, and each means design, development and testing. Two proposals can list the same number of screens and contain very different amounts of work. Requirements such as a multilingual interface, a dark theme and accessibility multiply the load of every screen. Ask: "Is the screen list written down, with its states counted?"
2. Back end and admin panel. Most apps need a server: user accounts, data, notifications, payment verification. An admin panel, the screen where content, users or orders are managed, is as much work as a small product of its own. If a proposal only says "mobile app," the first question is: are the back end and the panel included? Ask: "Who will manage the data, and from which screen?"
3. Feature type. A feature's load is not proportional to the number of screens. Payments and subscriptions bring store rules and a provider integration, location brings background permissions, chat brings real-time infrastructure, and offline use brings sync conflicts. Offline and real-time features are among the hardest to estimate. Ask: "Which feature is truly essential in the first version?"
4. Third-party integrations. Every integration depends on the other side's documentation quality, test environment, rate limits and error behavior. Connecting to your existing systems (stock, accounting, customer records) is a separate line item. Ask: "Which outside systems are in scope, and which remain on your side?"
5. Platform and technology choice. iOS, Android or both; one codebase or separate ones. The choice sets not only the initial development cost but also the maintenance load. The comparison criteria are on our mobile app development page. Ask: "Is the reasoning for the choice written in the proposal?"
6. Design depth, testing, release and maintenance. A custom design system versus the platform's standard components makes a difference in design and testing load. Testing grows with device and OS variety. Release covers store preparation and review, and maintenance covers operating-system updates. Ask: "In the first period after launch, who fixes what?"

A line-item cost model

The table below shows ten line items you should see in a proposal, how each should appear, and a question that keeps it from being left out. There are deliberately no weights, percentages or currency amounts in it: the share of each item varies from project to project, and this article prefers not to give a figure it cannot back up.

The right-hand column can be used together with the red-flag logic in our article on reading a software proposal: any row whose answer is not in writing may be a cost left outside the proposal.

Store rules are a cost item too

The rules the stores set create work that does not show up in the screen list but takes effort. Three examples from the official pages:

• Privacy declaration. Apple requires each app to declare in App Store Connect which data types it collects, whether they are linked to the user and whether they are used for tracking; third-party code in the app (analytics, ad networks, SDKs) is included (Apple). Google Play's Data safety section is mandatory for all published apps; apps that collect no data must still complete the form and link a privacy policy, data collected by third-party libraries goes into the declaration, and the developer is responsible for its accuracy (Google). This is both a writing task and an engineering task: you need to know what the app actually collects.
• Account deletion. According to Apple's review guidelines, an app that supports account creation must also offer account deletion within the app (5.1.1(v)) (Apple). Google Play asks apps that let users create accounts for an in-app deletion path and also a web page where a deletion request can be made even after the app is uninstalled (Google). The account deletion flow is a back-end line item; if it is not in the proposal it appears later as extra work.
• Privacy policy link. Apple requires every app to provide a link to its privacy policy in App Store Connect and within the app, easy to reach (Apple).

None of these is a "feature," but because they are store rules they can come up in review. Ask whether the "store preparation" line in the proposal covers them.

Ongoing costs outside the proposal

Mobile app development cost does not end with the development proposal. The costs below usually fall outside the proposal and are paid directly to the provider. The figures are taken from the official pages with the date they were read; they change over time, so reopen the pages before you decide.

The operating-system row matters most: an app is not finished on the day it is released. The stores' requirements rise every year, and that means engineering effort even if you add no new feature. Ask whether the maintenance line in the proposal covers it or whether it is charged separately.

How to work out an annual running budget

Splitting the ongoing costs into three types makes budgeting easier.

Annual running cost is, roughly: fixed costs plus unit price times expected usage plus maintenance labor. If you cannot estimate usage, do not inflate the guess; set a cap in the provider's console instead.

Why do proposals differ so much?

If three proposals are far apart in price, the reason may be that they are pricing three different jobs; bad faith is not needed. When the scope is not written down, every bidder fills the gaps with their own assumptions. A fictional example (no figures): the same "mobile app" request gets three proposals.

In such a table it would not be surprising for Proposal A to come out lower in price than the others: Android, the back end, the release and maintenance are left on your shoulders. "Assume the same scope" means filling in the table like this, adding the missing lines to every proposal, and only then comparing prices.

Quote comparison template

Copy the blank table below, fill it in for each proposal, and send the cells that stay empty to the vendor as written questions. In the cells write "written," "verbal" or "missing"; the "verbal" and "missing" cells say more than the price row. For questions focused on the contract and the scope document, also see the table in how to read a software proposal.

The price is at the bottom on purpose: compare what you are buying first, then what it costs.

A message you can send to the vendors:

Thank you for your proposal. To compare proposals on the same scope, I would be grateful for written answers on the following headings: scope and screen list (with states), platform and technical route with the reasoning, back end and admin panel, integrations, in whose name the store account will be opened, source code ownership, schedule and milestones, revision limit, testing and acceptance criteria, release support, maintenance period and scope, VAT status and payment plan. Please send the answers by email as part of the proposal.

Ready-made tool, freelancer, agency

We compared a ready-made tool, a freelancer, a software studio and your own team on our mobile app development page and do not repeat it here. One extra note for cost: in each option, different line items stay on your shoulders. For a ready-made tool, ask what happens to the app and the data when the subscription ends; for a freelancer, which items depend on one person and what happens if they leave; for a studio, whether the scope is written down and who writes the code. If a ready-made tool does the job, we say so openly.

Honest ways to lower the cost

1. Cut the scope. Start with one main flow; put each feature into one of the boxes now, later or never. We describe the method on our MVP development page. Cutting scope is the strongest lever for both cost and schedule.
2. Start with one platform. Which platform to start with depends on the devices your users have. Building both together or in sequence should be separate line items in proposals; leaving one for later lightens the first release.
3. Consider ready-made services. For authentication, payments, notifications and maps, a ready-made service can be faster than writing your own. In return come dependence and a usage fee; ask whether you could move away later.
4. Start with standard components in the first release. Custom animations and brand-specific components increase design and testing load; leaving them until after the first release is often possible.
5. Grow the first release by measuring. Make the second scope decision from what you learned in the first.
6. Plan the ongoing costs from the start. The table above is a budget line; it does not need to be a surprise after launch.
7. If you have an unfinished app, audit it first. Base the decision to rewrite or to continue on an audit rather than an assumption; the method is in taking over an unfinished software project.

How we write a quote

Here we only repeat what we say on our site. Scope, schedule and cost are in the written quote before work starts; work does not begin until you approve it, and once the scope is approved in writing the price does not change. Questions such as the store account and the release process are settled in writing at the quote stage. Unless you choose otherwise we set up and manage the infrastructure; if you have your own cloud accounts we deploy there. Ownership of the delivered work passes to you when the project fee has been paid in full. After launch we give a full year of direct support; support beyond that scales with the project. Details are on our mobile app development and Process pages. What binds is the written contract signed for your project.

Frequently asked questions

How much does it cost to have a mobile app built?

We do not give a single figure, because cost moves with scope: the number of screens and states, the back end and admin panel, the features, integrations, platform choice and maintenance expectations. The line-item table and comparison template in this article are for analyzing your own proposals. Once the scope is clear, the written quote holds scope, schedule and cost together.

Are iOS and Android apps built together?

Both are possible: with one codebase or with separate code for each platform. The choice depends on the product's needs and on the maintenance load, and it should be written in the proposal with its reasoning and as a separate line item. We put the reasoning for every technical decision in writing, including this one.

What does the app's annual running cost include?

The ongoing costs outside the development proposal: store accounts (US$99 per membership year for Apple and a one-off US$25 for Google Play, read from the official pages on October 24, 2026), servers and storage, usage of services such as notifications and SMS, domain and certificates, and the updates and maintenance needed as store requirements rise. The line-by-line list is in the table above.

Are the admin panel and the server included in the proposal?

Ask for them as separate line items. A line that says "mobile app" may or may not cover the back end and the admin panel; you cannot know without a written answer. Unless you choose otherwise, we set up and manage the infrastructure.

Why can a cheap proposal be risky?

Not as a moral judgment but as missing line items: a low price may not cover the back end, the admin panel, the second platform, testing, release or maintenance. The missing items then come back to you as extra cost. Fill in the comparison template; if the price difference comes from a scope difference, the table will show it.

Sources

The pages below were opened and read on October 24, 2026. Pages that carry fees, commissions and requirements change often; reopen them before you decide.

• Apple Developer Program: enrollment · Apple: upcoming requirements · Apple: App Store Small Business Program
• Google Play: developer account registration · Google Play: service fees · Google Play: target API level requirements
• Apple: App Store Review Guidelines · Apple: app privacy details · Google Play: Data safety section · Google Play: account deletion requirement
• Firebase pricing

This article is general information; it does not replace a proposal or a contract.