How to build an app that makes money, from 400+ apps with verified revenue

The short answer

The pages that rank for this search give the same six steps: define your purpose, research the market, plan, build, monetize, market. None of them says how much apps actually earn or which step most apps get wrong. This page uses two BigIdeasDB datasets to answer both: verified payment-provider revenue for mobile apps in TrustMRR, and 136,000+ app store reviews analyzed in our App Store research data.

Verified revenue means the number comes from the app’s payment provider, not from a founder’s post. We took every app in the TrustMRR “Mobile Apps” category with a revenue figure: 400+ apps. The distribution is steep. Most apps earn close to nothing, a small group earns a living, and a handful earn a business.

Two numbers frame the rest of this page. $1,000 a month is where an app starts to be worth the evenings: 68 of 417 reach it. $10,000 a month is where it can replace a salary: 15 reach it. Health and fitness looks the same. Of 300+ verified health and fitness products the median earns $12 a month and 6 earn $10,000+.

None of this says apps are a bad bet. It says the default outcome of building an app is a small one, and the steps below are about moving off the default. If you want to model a specific niche, the free app store revenue calculator turns a price and a conversion rate into a monthly figure.

Money shows up in year two, not launch week

The most useful split in the data is age. We grouped the apps that state a founding date by how long they have existed. Revenue climbs steadily with age, and the share of apps earning $1,000+ a month nearly doubles between year one and year three.

Read this two ways. First, survivors bias it: apps that failed in year one are less likely to still list revenue in year two, so older apps look better partly because the weak ones left. Second, even with that bias, it sets the right expectation. An app that earns $22 a month after six months is the median, not a failure. The decision point is whether the number moves, and whether the people paying are the people you built it for.

That is why the steps below spend more time before the build than during it. Building is now fast. Waiting a year to learn you picked the wrong problem is not.

How to build an app that makes money, step by step

Eight steps. The first four happen before you write code. Each ends with the check that tells you whether to move on.

1. Pick one narrow problem with proof people already pay

Start with a problem, not an app category. “A better fitness app” is a category. “Tracking meals without typing them in” is a problem. Scan the app store top charts in a few categories and write down apps that do one specific job for one specific person. Those are the shapes that earn in our data: every app above $10,000 a month with a description does one personal thing, such as analyzing a face, a color palette, a meal or a sports bet.

Check: can you say who has the problem and what they do about it today in one sentence? If not, keep narrowing. The BigIdeasDB discover flow and the mobile app idea generator both start from complaints rather than categories, which forces the narrowing.

2. Read the 1 and 2 star reviews of the apps you would replace

Five-star reviews tell you what works. One- and two-star reviews tell you what people would pay to fix. Pull the low-rated reviews for the top 10 apps in your niche and group them by complaint. You are looking for the same missing thing mentioned again and again, in plain words.

“Not a single decent plant app out there.”2-star review of a plant care app

A review like that is a demand signal with a reason attached. Across our dataset, 6,000+ low-rated reviews contain a request (“wish it had”, “please add”), which makes the reviews a free product roadmap. BigIdeasDB’s App Store research groups them for 7,700+ apps across 260+ niches, so you can read the pattern for a niche in minutes instead of scrolling for an afternoon. Our state of mobile app pain points report shows the biggest themes by category.

Check: do at least three complaints repeat across different apps in the niche? One angry reviewer is noise. The same complaint about five apps is a gap.

3. Confirm the money with verified revenue

Complaints prove pain. They do not prove people pay. Before you build, find apps in the same niche with verified revenue. If several earn $1,000+ a month, the niche pays and you are competing on the complaint. If none does, either the niche does not pay or nobody has found the right angle yet, and you should know which before you start.

Competition is a good sign here, not a reason to quit. An earning incumbent with a pile of one-star reviews is the best setup in this whole process: proven demand plus a known reason people want to switch. Look up the niche in TrustMRR or the revenue intelligence view.

Check: at least one app in the niche earns a verified $1,000+ a month, and its reviews contain the complaint you plan to fix.

4. Write the pitch before the code

Turn the most common complaint into a one-line promise, in the words the reviewers used. One 2-star plant care review says the app was “unable to find just about every plant I had”. A plant app built from that promises to identify every plant, not “smart plant care”.

Then put that promise in front of people who have the problem, before the app exists. Short-form video, a post in a community where the problem gets discussed, or a one-page site with an email box all work. Try three to five different ways of saying it: a personal story, a before and after, the complaint read out loud. Watch the replies more than the view count. “What is this called?” and “I have this exact problem” are the signals. Jokes and likes are not.

Check: one version of the pitch gets people with the problem asking for the product. If no version does after a few rounds, change the idea, not the wording. An app does not fix a pitch nobody wants.

5. Ship a version one that fixes one complaint

Version one does the single action your promise describes, and does it well on a real phone. Leave out the social feed, the second use case and the AI coach. Large apps carry those because they already know what their users want. A new app does not, yet.

Reliability is part of the product. 8,000+ low-rated reviews in our dataset are about crashes, bugs and freezes, and 2,600+ say an app got worse “since the update”. A small app that never crashes beats a big one that sometimes does. AI app builders make a first version cheap; we covered what that costs and earns in do vibe-coded apps make money.

Check: watch five real people use it. Do they reach the action you promised without help? If they expected something else, fix that before you add anything.

6. Charge in a way reviewers do not punish

Pricing is the biggest complaint class in our review data, so it gets its own section below. The short version: show the price before sign-up, make the free part genuinely useful, put cancellation one tap away inside the app, and offer a lifetime tier next to the monthly plan.

7. Measure paying users, not views or downloads

Once people start arriving, track one number per source: how many of the people it sends start paying, and how many are still paying a month later. Views and downloads are inputs. See the measurement section for what to watch.

8. Scale only the angle that converts

When one message and one channel bring paying users, do more of exactly that before you try anything new. Make variations of the winning pitch (a different opening line, a different example of the same problem) and keep the core promise fixed. Only then spend money: run the best-performing versions as small paid tests and keep the ones that bring payers at a cost you can carry. A second channel can wait until the first one stops growing.

We counted complaint types across the 99,000+ reviews rated 3 stars or lower in the BigIdeasDB App Store dataset (7,700+ apps, 260+ niches). A review can fall into more than one row. Treat each row as a list of things your version one should not do.

Two things stand out. Money complaints outnumber bug complaints, so a polished app with a hostile paywall still loses. And the niches with the most one- and two-star reviews are crowded consumer categories: news, productivity, travel, food delivery, dating, shopping, finance, music, photo editing, fitness, meditation and language learning. Those are not niches to avoid. They are niches where a new app can win by fixing what users already hate. The find a gap in the app market guide shows how to turn one of these rows into a specific idea.

How to charge without earning 1-star reviews

Most earning apps charge a subscription, and the reviews show exactly where subscriptions go wrong. Five patterns cover most of the 10,000+ price complaints:

• The surprise charge. 1,500+ low-rated reviews mention a free trial, many of them because it turned into a charge the user did not expect.
• The hidden price. Users sign up, answer questions, and only then see the paywall.
• The cancel maze. 4,300+ low-rated reviews mention cancelling and 2,800+ mention refunds.
• The paywall on everything. 1,000+ mention a paywall directly, often because nothing is usable free.
• The upsell loop. Prompts to subscribe on every open.

“They said it was a free trial yet 70 dollars were taken out of my account instead.”1-star review of a meditation app

“The app initially presents as “free” but only begins discussion of subscription fees AFTER you complete the registration process.”1-star review of a plant care app

“predatory auto renew. cancelled a year subscription less than 24 hours after it auto renewed.”1-star review of a language learning app

“Everytime I open the app I have to go through a series of questions and prompts to pay for a subscription.”1-star review of a meditation app

The fixes are cheap. Send a reminder two days before a trial converts. Put the price on the first screen that mentions upgrading. Make cancellation a single button in settings. Let the core action work free a few times so people know what they are paying for. And offer a one-time or lifetime price: 1,100+ low-rated reviews ask for one. One long-time user of a period tracker put the cost of getting this wrong plainly:

“I now am looking at a pay wall to remove ads with a subscription. I’m so disappointed and will not be paying again.”1-star review of a period tracker app

For the full trade-off between models, see subscription vs one-time purchase.

How much can an app with 1,000 downloads make?

Downloads do not pay; subscribers do. Among the 61 mobile apps earning $1,000+ a month that report active subscriptions, the median brings in about $8 a month per active subscription (BigIdeasDB TrustMRR, October 2026). That makes the math simple:

• 1,000 downloads, 5% subscribe: 50 subscribers, about $400 a month.
• 1,000 downloads, 0.5% subscribe: 5 subscribers, about $40 a month.
• $10,000 a month at $8 per subscriber needs about 1,250 paying subscribers at once.

We do not have download counts, so we cannot give a verified revenue-per-download figure, and anyone who quotes one without naming a source is guessing. The useful takeaway is the subscriber target. Work out how many paying users your goal needs, then ask whether the niche from step 3 has that many people with the problem.

What the top-earning apps have in common

We read the 68 mobile apps earning $1,000+ a month. Four patterns hold:

• Consumer, not business. 34 of the 36 that state an audience sell to consumers.
• One personal outcome. The highest earners analyze a sports bet, a face, a color palette or a meal, deliver faith content, help write a dating reply, or forecast the weather. Each does one thing for one person.
• AI as the engine, not the pitch. 16 of the 38 with a description mention AI, but none sells “AI”; they sell the result.
• Revenue has to be defended. Of the 42 that report a non-zero 30-day change, 28 were shrinking that month, with a median change of minus 9.3%. Subscriptions churn, so a top app needs a steady flow of new payers just to stay level.

That last point is why step 8 matters. An app that reaches $10,000 a month on one lucky post and then stops posting gives it back. For more niches that fit the pattern, see profitable mobile app ideas and problem-solving app ideas.

Measure payers, not views

A post with a million views that brings no paying users costs you a week. Paying to show it to more people costs you money as well. The trap is easy to fall into because views are the first number you see. Track these instead, per post or channel:

• Who replied. Are the comments from people with the problem (“I deal with this every day”) or from people enjoying the joke?
• Install to paid. Of the installs it sent, how many started paying?
• Paid at day 30. How many still pay a month later? This is where a mismatched pitch shows up.
• Cost per payer. Once you spend money, divide spend by new payers, not by installs.

When a message works, use the same words everywhere: the store listing, the first screenshot, the onboarding. Someone who installed because of a specific promise should see that promise first. A generic chart or a feature tour on the first screen breaks the thread that brought them in.

Before you build anything else, run the idea through BigIdeasDB discover: it checks the niche against 1M+ complaints, the low-rated reviews of the apps you would replace and verified revenue, so steps 1 to 3 take an afternoon instead of a month.

What this data cannot tell you

Every figure comes from BigIdeasDB data read with read-only SQL on October 11, 2026. Six limits matter:

• Verified does not mean representative. TrustMRR covers apps whose founders connected a payment provider. Apps that earn nothing may be less likely to connect, so the true median for all apps is probably lower than $42.
• Survivorship in the age table. Apps that failed early drop out, which flatters the older groups.
• No download data. We cannot give revenue per download or conversion rates from installs.
• Reviews are sampled low. The App Store dataset deliberately over-samples low ratings, so we show complaint counts, never a share of all reviews or a satisfaction score.
• Keyword classes are approximate. Complaint types are matched with keyword patterns. A review can match several classes, and some matches will be loose.
• Small groups. The top-earner patterns come from 68 apps, and the audience split from the 36 that state one. Read them as patterns, not laws.

One thing we tested and could not support: that older apps earn more because they are better. The age effect is real in the medians, but survivorship explains part of it and our data cannot separate the two.

Methodology and data sources

Revenue figures use every app in the TrustMRR “Mobile Apps” category with a monthly revenue figure (n = 417). Revenue is in US dollars as reported by the payment provider. Age uses the stated founding date; two apps with a future founding date and 111 with none are excluded from the age table. Revenue per subscription divides monthly revenue by active subscriptions for apps earning $1,000+ a month that report subscriptions (n = 61). Complaint counts use regular-expression classes over the text of reviews rated 3 stars or lower in the App Store dataset. Every figure is a median or a count.

Frequently asked questions