How to make money from an app: seven models, store fees and a worked example

Can you make money from an app at all?

Yes, some apps make money, but nobody can promise yours will. Revenue depends on whether people have the problem, whether they find the app, and whether they will pay. The first of those is the one you can test cheaply, which is why the guide to validating an app idea comes before any pricing decision.

What this page can do is show you the models that exist, the costs that sit between a customer’s payment and your bank account, and a way to run the numbers before you build. If you are still looking for something worth charging for, app ideas to make money lists concrete ones.

What are the main ways to make money from an app?

There are seven models in common use. Most successful small apps pick one and do it well. Mixing three on day one usually confuses the user and the code.

A model is not the same as a price. Choosing a model answers “who pays and when”. Pricing answers “how much”. Settle the first before you argue about the second.

How do free apps make money?

A free app is free to the person who installs it. Somebody else, or a small slice of those users, pays. There are four routes:

• Ads. Advertisers pay to show their message inside the app. It works for apps with many daily users. For a small utility with a few hundred users, ad income is usually too small to matter, and the ads make the app worse.
• Freemium. The core use is free, and a minority of users pay for an upgrade, higher limits or extra features. The free tier has to be good enough that people stay, or nobody reaches the paywall.
• Free trial into subscription. Everyone can try the full app for a short time, then pays to continue. The store lets you set this up inside its subscription tools.
• Free for the user, paid by a business. The app is free for employees or customers, and the company pays for the account. This is how many B2B tools work.

Freemium and trial-based subscriptions suit most small apps built with an AI agent. They let you ship without asking for money up front, and they give you a number to watch: the share of free users who pay.

What do Apple and Google keep from each sale?

If you sell digital features inside an iPhone or Android app, the store takes a commission, and the rules decide whether you may use another payment method. Read the current official pages before you set a price, because rates differ by market and program and have changed more than once.

Two things follow. First, you cannot simply link out to your own checkout for an in-app subscription and avoid the fee; each store rejects that for most digital goods, and some regions have separate rules. Second, a web app does not pay store commission at all, because it does not go through the store. That is a real reason to start on the web: you keep the whole payment minus the processor’s fee. The guide to making an app for free covers account costs in more detail.

How do you work out what an app might earn?

Work backwards from costs. Revenue forecasts built on hope are the usual way people fool themselves. This example is arithmetic, not a prediction: every input is something you must replace with your own measured number.

Look at what the example shows. A thousand active users and a respectable conversion rate still produce a small monthly sum. Doubling either the price or the number of users matters far more than polishing a feature. And if your app calls a paid AI model, the usage bill grows with every active user, which can eat the margin. The AI app guide shows how to cap that cost.

Tax is not in the table. Depending on where you and your customers are, sales tax or VAT may apply, and the store or your payment processor may handle some of it. Find out which before launch, not after the first payout.

Which model fits your app?

Answer these in order and stop at the first line that fits.

1. The app has running costs per use (AI calls, SMS, maps, storage). Use a subscription or credit packs, so revenue grows with cost. Do not use ads.
2. The app does one job once (convert a file, plan a trip, compare a bill). Charge per use or sell a small paid upgrade through in-app purchase, or keep it free as a lead for something larger.
3. The app is used daily by a company team. Sell per seat or per account. Ask three companies what they pay for the current workaround.
4. The app is a game or a casual toy with a very large audience. Ads and optional purchases are the usual pair. Without a large audience, neither pays.
5. You have no idea who would pay. You are not ready to pick a model. Go back to the idea and talk to people.

A board idea can show how this plays out. Photograph any bill and see if you’re overpaying is a one-job tool, so a fee per scan or a small bundle fits better than a monthly plan. Browse finance ideas on the board and ask of each one: who pays, and when?

How should you price it?

• Start from cost, then from value. Your floor is what each user costs you to serve. Your ceiling is what the problem costs them today. Price between the two.
• Show value before the paywall. Let a new user complete the app’s main job once. Asking for money before they have seen the result converts badly.
• Offer one plan before you offer five. One monthly price and one yearly price are enough for a first version. More tiers add decisions for the user and work for you.
• Charge earlier than feels comfortable. A small price tests whether the problem hurts. Free users tell you less than the first ten people who pay.
• Change the price on new customers, not old ones. You can test a higher price with the next batch of users.

For software sold to small businesses, how to price a micro SaaS goes deeper. If you plan to add accounts and billing to a web product, how to build a SaaS covers the pieces.

How do you get your first paying users?

Before you build a paywall, find out whether anyone will pay. You can do that by hand.

1. Show the working prototype to the people you interviewed and ask: “I am charging a small monthly fee. Would you pay it today?”
2. If they say yes, take payment through a simple payment link on a web version, even if the product is rough.
3. If they say “maybe”, ask what would make it a yes. Write down the answer.
4. Only then build the in-app purchase flow, once for the platform where those users actually are.

Before you build anything, check the App Idea Validation Planner, which turns your idea and target user into questions and a small experiment. Reaching people is its own task; the launch guide for people with no audience and the guide to marketing an app cover it.

What mistakes cost the most?

• Adding ads to a tiny app. A few hundred users produce pennies, and the ads drive some of them away.
• Building billing before demand. Payment code is the dullest part of an app and the easiest to get wrong. Test willingness to pay first.
• Breaking the store’s payment rules. Linking to an outside checkout for an in-app digital feature can get an update rejected or an app removed. Read guideline 3.1 and the Google payments policy before you design the paywall.
• Ignoring running costs. A free tier that calls a paid AI model for every user can cost more than the app earns.
• Copying a price from a bigger product. Their cost structure and audience are not yours.
• Forgetting refunds and support. Someone will ask for money back. Decide your policy and read the store’s refund rules before launch.

I am building [app name], an app for [specific user] that does [one job].

Revenue model I am considering: [subscription / paid download / in-app purchase / ads / per-seat].
Platform: [web / iPhone / Android].

Costs per active user each month: [hosting, database, AI usage, other].

Do this, in order:
1. Ask me up to five questions that would change the model.
2. Using only numbers I give you, build a table of gross billings, store commission and costs for 100, 1,000 and 10,000 active users. Mark every assumption.
3. Tell me the smallest version of billing I can ship first, and what to leave out.
4. List the store payment rules I must check before launch, with links to the official pages. Do not guess rules you cannot cite.

Keep the last line of that prompt. An agent that is allowed to guess store rules will state them confidently and sometimes wrongly.

What if you have an idea but will not build it?

Then your best revenue option is not an app at all. Post the idea on the board, free and with no account. Every idea gets a generated build prompt, so a builder can pick it up. Posting earns you nothing directly, but it can put the idea in front of someone who builds it.