How much to charge for a mobile app
How much to charge for a mobile app depends on three things, and you price each one on its own line: the build, the store launch, and the upkeep afterwards. Quote the build and the launch as a fixed fee in three tiers, sized against what the app is worth to the client's business, not against your hours. Quote the upkeep as a monthly fee. Keep the store accounts and their fees in the client's name. Do not quote build hours. With Claude Code, the first working version of an app can come together quickly, and a client who hears how quickly will price the whole thing like a weekend job, when the launch and the upkeep are where most of the real work sits.
This is where new builders lose money on apps. They price the part that got faster and give away the two parts that did not. Getting an app approved and listed, and keeping it working as phones and store rules change, takes the same patience it always did. If the quote is one number for "the app", the client assumes all of that is included forever. It needs to be written down and priced, or you are doing it for free a year from now.
A mobile app is not priced like a website
A website goes live when you say so. A mobile app goes live when a store says so, and that one difference changes the whole quote. There is a gatekeeper between you and the client's customers, there are accounts and fees that have to exist before anything ships, and there is no such thing as finished, because the phones keep changing underneath it.
Website or mobile app: what changes in the quote
| Website or landing page | Mobile app | |
|---|---|---|
| Who decides it goes live | You and the client | The app store, after its own review |
| Accounts needed first | A domain and hosting | A developer account on each store, in someone's legal name |
| How a fix ships | You publish it | You submit an update and it goes through the store again |
| What breaks it later | Rarely anything, if left alone | New phone software, new screen sizes, new store requirements |
| What you price | The page and what it converts | The build, the launch, and the upkeep as three lines |
Walk the client through this table on the call. Most have never shipped an app and assume it works like their website. Once they see the launch and the upkeep as real work with real steps, a quote with three lines stops looking padded and starts looking like you have done this before. For the website side of the comparison, how much to charge for a landing page has that quote.
Ask first: does it need to be in the app stores at all?
Often the honest answer is no. When a client says "we need an app", what they usually mean is "our customers are on their phones". A web app that works well on a phone covers that with no store account, no review and no waiting on anyone to publish a fix. It is a smaller quote and a faster delivery. Four questions tell you which one they need.
- Who will use it? If it is the client's own staff, a web app they open from a link is almost always enough. If it is the public, the store listing may matter.
- What must it do that a website cannot? Features that depend on the phone itself are the real reasons to go native. "It should have an icon" is not one.
- Do customers need to find it in a store? Some businesses get real value from being listed. Many will only ever send people a link, in which case the store is pure overhead.
- Who will look after it in a year? If the answer is nobody, the simpler option is the responsible one.
Telling a client they need the cheaper thing feels like leaving money on the table. It is the opposite. It is the moment they decide you are the person they trust with the budget, and when they do need the store version later, nobody else gets the call. The full question set is in client discovery questions before you quote.
The CCC Store-Ready Ladder: three tiers
Present three tiers for the same app and let the client choose how far they want to go. The tiers are not more screens. They are how close the app gets to the public, and how much of what comes after you take on.
The CCC Store-Ready Ladder
| Tier | What the client gets | How to price it |
|---|---|---|
| Pilot | A working app with the core feature, running on the client's own phones and a small group of testers. Not listed publicly. One round of changes after they have used it for a week | A fixed fee sized against the one job the app does. The easiest yes, and the honest starting point when nobody is sure customers will use it |
| Store Launch | Everything in Pilot, plus the app finished to a public standard and published on one store: the listing text and screenshots, the privacy details the store asks for, the submission, and handling whatever the review sends back | The anchor tier. The fee covers the launch work as its own line, because a rejected submission is your time whether or not you planned for it |
| Launch and Run | Everything in Store Launch on both stores, plus a monthly plan: updates when phone software changes, fixes, store requirement changes, and a short monthly report | The build and launch fee plus a monthly fee. Priced like keeping a product alive, because that is what it is |
Most clients land on Store Launch once they see the table, and that is fine, provided the upkeep conversation still happens. If they decline the monthly plan, write down what that means: updates and fixes after the handover period are quoted separately. The three-tier shape is the same one I use in how much to charge for an AI agent; the tiers change, the logic does not.
Store accounts and fees go on their own line, in the client's name
The store accounts belong to the client, and so do the fees. The Apple Developer Program is 99 USD per membership year. Google Play charges a US$25 one-time registration fee for a developer account. Neither number is large. The reason they go on their own line is ownership, not cost.
- The client opens the accounts in their own legal name and adds you as a team member. If the app is published under your account, the client does not really own their own product, and you cannot walk away without taking it down.
- Start the accounts on day one. Both stores ask for identity details before they let anyone publish, and that is time you do not control. It should never be the thing holding up the launch.
- List the fees on the quote as paid by the client directly. You are not marking them up and you are not fronting them.
- If the app sells anything through the store, tell the client that the stores take a commission on those sales and point them to the store's own current terms. Do not quote them a percentage from memory. That decision shapes their pricing, and it is theirs to make with the real numbers in front of them.
Put the ownership in writing along with the fees. What to put in an AI project contract covers the clause, and how to hand off a Claude Code project covers what the client should hold at the end: the accounts, the code, and the logins for anything the app depends on.
What moves a mobile app quote up or down
- One store or two. Two listings means two accounts, two sets of store requirements and two submissions. Quote the second store as its own line so the client can defer it.
- Accounts and logins. An app where people sign in needs sign-up, password reset, account deletion and somewhere safe to keep the data. It is never "just a login".
- Payments. Taking money inside an app brings the store's rules with it. Scope it as its own piece of work, and find out early which rules apply to what the client is selling.
- Working without a signal. If the app has to work offline and catch up later, that is a meaningful jump in the build and the testing.
- What it plugs into. An app that reads from the client's booking system or stock system is only as reliable as that connection. Every system it touches is a line.
- Notifications. Sending alerts to people's phones needs setup on each store and a plan for who writes and sends them.
- Design. A client with finished designs is a smaller quote than one who wants you to work out how it should look and feel.
- Who owns the upkeep. If the client has someone technical, the monthly plan is lighter. If that someone is you, it is in the price. How to price a maintenance retainer covers the number.
The mistakes that leave you maintaining an app for free
- One number for "the app". If launch and upkeep are not separate lines, the client assumes both are included, for good.
- Publishing under your own developer account. It feels faster. It ties you to the app permanently and leaves the client without control of their own product.
- Promising a launch date you do not control. You control the day you submit. The store controls the day it goes live. Quote a submission date and say so plainly.
- Treating a store rejection as a surprise. Write into the quote that responding to review feedback is included, and how many rounds. How many revisions to include in an AI project has the wording.
- No upkeep plan and no written alternative. An app with no monthly plan and no stated rate for later fixes becomes an argument the first time a phone update breaks something.
- Building for both stores before anyone has used it. Launch on one, learn what customers do with it, then add the second as a paid step.
- Letting the feature list grow mid-build. Apps attract "while you are in there" requests. How to handle scope creep on client projects has the reply.
- No deposit. How much deposit to charge before an AI project covers the number. An app is a multi-week commitment and gets paid like one.
How to present the mobile app number so it closes
Lead with the job the app does for the business, then put the three tiers under it with the store fees and the monthly plan written out beside them. "You said your regulars keep asking to rebook from their phones; here are three ways to give them that, depending on how public you want it on day one" is a sentence a client can say yes to on the call. Send it as a one-page proposal with the job in one line, the tiers, the submission date, who owns the accounts, and what happens after launch. If they push on price, the answer is the Pilot tier, not a discount, and the "can you do it cheaper" objection has the words.
An app that is live and looked after is the best retainer you will sign, because the client sees it on their own phone every day. How to turn a one-off client into a monthly retainer is what happens next. If you have not built one yet, build a mobile app with Claude Code is the build side of this post.
Short, practical drops on skills, MCP, agents, prompts, and more. No spam, unsubscribe anytime.
Frequently asked questions
How much should I charge for a mobile app?
Price three things separately: the build, the store launch, and the upkeep. Quote the build and launch as a fixed fee in three tiers sized against what the app is worth to the client's business, and quote the upkeep as a monthly fee. Do not quote build hours.
Who should pay for the Apple and Google developer accounts?
The client, in their own legal name, with you added as a team member. The Apple Developer Program is 99 USD per membership year and Google Play has a US$25 one-time registration fee. Put both on their own line of the quote as paid by the client directly.
Should I charge a monthly fee for a mobile app?
Yes, or state in writing what happens without one. Phone software, screen sizes and store requirements keep changing, and an app that is never updated eventually breaks. The monthly fee pays for updates, fixes and store changes. If the client declines, write down that later work is quoted separately.
Is a web app cheaper than a mobile app for a client?
Usually, yes. A web app that works well on a phone needs no store account, no store review and no resubmission for every fix, so both the build and the upkeep are smaller. Go to the app stores when the app needs features that depend on the phone itself or when being listed in a store matters to the business.
Should I quote iOS and Android together?
Quote them as separate lines. Two stores means two accounts, two sets of requirements and two submissions. Launching on one store first, then adding the second as a paid step once customers are using the app, is the lower-risk path for most clients.
Last reviewed by Duncan Rogoff on September 30, 2026
