US | Pricing | 2026-08-16

What a Custom Mobile App Actually Costs

Same brief, wildly different quotes: here is what really moves the price, and which bills show up months after launch.

Two studios can read the same one-paragraph brief and come back with $3,000 and $40,000 without either one padding the number. "App" describes a styled catalog that pulls from a database and emails the owner when someone taps Request a Quote. It also describes a two-sided marketplace with identity checks, split payouts, refund disputes, and a nightly job that reconciles them. The distance between those two is engineering, not margin.

So the useful question is not what an app costs. It is which cost drivers your app actually touches, and how hard it leans on each one.

The four variables that set the number

Screen count, weighted by logic. A list screen and its detail screen are close to free once the first pair exists, because the data layer, navigation, and design system are already paid for. Screens that carry their own state are a different animal: a multi-step booking flow with availability rules, a checkout, a chat thread, an approval queue. A 22-screen catalog app can cost less than a 9-screen app where three of those screens hold logic.

Backend shape. Read-only content that one person edits is the cheapest backend that exists. Price climbs when users write data, when two users can write the same record, when something must happen with nobody holding the phone (reminders, expirations, recurring charges, nightly digests), and when roles diverge. Customer, staff, and owner is not one app with three menus. It is a permission matrix, and every permission matrix has to be tested against people trying to reach data that is not theirs.

Integrations, counted one at a time. "Add Stripe" can mean an afternoon (single card charge, hosted payment sheet, one webhook) or three weeks (connected accounts, KYC onboarding, delayed payouts, application fees, partial refunds, dispute webhooks, and a reconciliation view a bookkeeper can read). Same three words, two orders of magnitude. Calendar sync, POS systems, accounting software, an existing SQL database behind a VPN, and any partner whose API documentation arrives as a PDF all belong in this bucket. Ask for them to be priced individually.

Platform and release surface. One codebase shipping to two stores is the normal case and is not where the money goes. Cost lives outside the phone: a web admin panel so you are not editing records in a database console, a tablet layout that is more than a stretched phone, an offline mode, a watch companion, a kiosk build for in-store hardware.

What is genuinely cheap, and what is genuinely expensive

Cheap once the foundation exists:

• Extra content-driven screens, theming, and rebrands
• Push announcements sent from a dashboard
• Forms that write a record and send an email
• Onboarding, deep links, share sheets, review prompts
• Search and filtering over data the app already loads

Expensive almost regardless of who builds it:

• Offline-first sync with conflict resolution
• Real-time shared state such as live bidding, presence, or collaborative editing
• Video or voice calling, plus the per-minute infrastructure bill behind it
• In-app chat once reporting, blocking, and moderation are required
• Background location, background Bluetooth, continuous audio
• Money moving between two parties who are not you
• Anything that touches health records or raw card data directly

If your feature list sits entirely in the first group, a five-figure quote deserves questions. If it contains two items from the second, a low quote deserves more.

What $2,500 buys against what $7,000 buys

Read that table as scope, not quality. The lower tier is a finished product with a narrow surface, not a degraded version of the upper one. Owners who overspend usually do it by specifying tier-three features they will not touch in year one, then paying to maintain them anyway.

The bills that arrive after launch

These are small individually and surprising in aggregate, mostly because nobody puts them in the proposal.

• Apple Developer Program: $99 per year, per organization. Let it lapse and your app comes off the store.
• Google Play: $25 one time, per developer account.
• Firebase: $0 on the free tier for a quiet app. Spikes come from data modeling, not traffic. A feed that reads 200 documents on every refresh instead of one aggregated document is how a $3 month becomes a $180 month.
• Push: Firebase Cloud Messaging costs nothing. The Apple side still requires the paid program and a key someone has to rotate when it goes missing.
• Domain and email: roughly $15 a year for the domain, $0 to $20 a month for transactional email once you send receipts.
• Payment processing: card fees run near 2.9% plus 30 cents in the US. If you sell digital goods that must go through in-app purchase, Apple and Google take a platform commission instead, with a reduced rate for smaller developers.

The line item people actually miss is the operating system calendar. Apple and Google each ship a major OS release every fall, and Google Play raises its minimum target API level about a year behind each Android version. That guarantees at least one forced technical update annually even if your product never changes: a dependency stops compiling, a permission behaves differently, a signing certificate expires on a Friday. Budget one or two maintenance releases a year, and budget them as real work rather than a favor.

Where quotes go wrong

1. Priced by screen count. It ignores the logic behind the screens and it ignores admin tooling entirely. Someone has to add products, approve users, and issue refunds. If the quote does not say where that happens, it happens in a database console, and you will hate it.
2. Integrations bundled into one line. "Payments and calendar" is not a line item. It is two projects with independent failure modes.
3. No account ownership named. The Apple and Google accounts, the Firebase project, the domain, and the repository should sit in your organization's name from day one. Transferring an app listing later is possible and tedious.
4. Source code left ambiguous. If the contract does not say you receive the full source, assume you do not, and price the rebuild you may eventually need.
5. Store review treated as a formality. Rejections are routine. Common causes include an app reviewers judge to be a repackaged website, digital goods sold outside in-app purchase, missing in-app account deletion, and privacy disclosures that do not match what the app collects. Each round trip costs days.
6. Content migration unscoped. Importing 900 products with photos from a spreadsheet someone maintained by hand is a real task with a real number attached.

How to get a quote that holds

Write one paragraph describing what a customer does in the app on their first visit, start to finish. List every external system it must talk to by name. Say who administers content and where they do it. Name the three things that must work on launch day and the five that can wait until version two. A brief like that produces quotes that vary by roughly 30% instead of 400%, and the variance that remains reflects a real difference in what is being offered rather than a difference in what each side assumed.