Does a Solo Mobile App Actually Make Money?

You built the app. It runs, it looks decent, it is live on the store. Now you refresh the dashboard and there are four downloads, and two of them are you on different phones. This is the moment almost every solo app developer hits, and it is not a sign you built the wrong thing. It is a sign that shipping an app and getting an app to make money are two completely different projects. This guide is about the second one: whether a mobile app built by one person actually makes money, how the money works, and the part the "just build an app" advice always skips.

Where does the money actually come from?#

The money comes from one of four places, but every one of them passes through the same two gates first: someone has to find the app, and someone has to keep using it long enough to be worth something. The store sits in the middle and takes a percentage of anything you charge inside it.

                A person who needs what your app does
                                |
                                v
                Finds it (store search, ads, your own audience)
                                |
                                v
                        Installs the app
                                |
                                v
                    Actually uses it (most do not)
                                |
        +-----------------+-----------------+------------------+
        v                 v                 v                  v
   Paid download     Subscription /     Ads shown to      Free app feeds
   (one-time)        in-app purchase    active users      a paid service
        |                 |                 |                  |
        v                 v                 v                  v
   Store takes a     Store takes a     Ad network pays   You bill outside
   cut, you keep     cut each month,   per view/click,   the store, keep
   the rest          you keep the rest you keep the rest almost all of it

The thing to notice is that the store takes its cut on anything sold through it, and that discovery step near the top is where almost everyone leaks out. You can have a great app and a fair price and still earn nothing if nobody with the problem ever finds it. This is the same pattern behind most online businesses, where attention has to turn into a paying relationship. If you want the general version, where does online money come from walks through it, and distribution beats product makes the case that the finding step is usually what decides the outcome.

How it actually works#

Start with the store cut, because it changes the math on everything. The major app stores generally take about 30 percent of what you charge, dropping to about 15 percent for small developers who qualify for reduced-rate programs and for subscription revenue after a customer has stayed subscribed a while. The exact terms shift over time and vary by store, so confirm the current numbers before you price. The point that does not change: a meaningful slice of every dollar sold inside the app goes to the platform, and you build your plan on what is left.

Then there is review and ratings. Every update goes through an approval process that can take hours to days, so you cannot ship a fix the instant something breaks the way you can on the web. Ratings compound too: a few early one-star reviews from confused users can sink an app before it gets going, while steady good ratings slowly make the store more willing to surface you. You are managing a reputation, not just a codebase.

Now the hard truth about discovery. The store has millions of apps and a search box most people barely use. Ranking for a useful search term is app store optimization, or ASO, and it is real work: the right title, keywords, screenshots, and a description that matches what people actually type. But even good ASO usually is not enough alone. The apps that grow bring their own traffic, from an audience, a community, content, ads, or an existing product. The store rewards apps already getting installs and good engagement, which means you often have to create the early momentum yourself before the store helps at all.

Retention runs underneath all of it. An install is not a customer. Most people who install an app open it once or twice and never come back, so the number that matters is not downloads but how many are still using it a week or a month later. That is why the apps that make money as solo projects almost always solve a recurring need, something a person comes back to on purpose, not a one-time novelty they try and forget.

A simple worked example (hypothetical)#

Let me put numbers on it so the model is concrete. These are invented to show how the pieces interact, not a promise or a typical result. Your real numbers will be different.

Say you build a subscription app for a specific niche and charge 5 dollars per month. You manage to get 1,000 downloads in a month through a mix of posting where these people gather and a little ASO. Assume:

• Of 1,000 downloads, about 100 actually start the free trial (a 10 percent hypothetical trial rate).
• Of those 100 trials, about 20 convert to a paid subscription (a 20 percent hypothetical conversion).
• That is 20 paying subscribers at 5 dollars, so 100 dollars of gross subscription revenue that month.
• The store takes roughly 30 percent, leaving you about 70 dollars.

So 1,000 downloads turned into about 70 dollars for the month. That is the number that surprises people. It is not because the app is bad. It is because a download is several steps away from a dollar, and the store takes a piece of the dollar that does make it through.

Now flip one lever. If you improved onboarding so 200 people started the trial instead of 100, and the same 20 percent converted, you would have 40 subscribers and roughly 140 dollars after the cut, double the revenue from the same 1,000 downloads. Or if those 20 subscribers stayed 12 months instead of canceling after one, each is worth far more over time even though the monthly number looks small today. Raw downloads are the least important number in the chain. The trial rate, the conversion rate, and how long people stay are what move the money, and all three come from the product being genuinely useful to the right person.

Compare that to an ad-only version. If you showed ads instead of charging, you might earn on the order of a few dollars per thousand active users per day, and the rate swings wildly by country, format, and how often people open the app. To turn ads into real money you need a large base using the app frequently, which is exactly what is hardest to get as a solo developer. That is why ad-only is usually the toughest road, not the easy one it looks like.

What you need#

You do not need a big team, but you do need more than the ability to code.

Required:

• A narrow, recurring problem a specific group of people has. Not "an app for everyone." Something like "runners who follow a specific training plan need a simpler way to log workouts offline."
• The ability to build and maintain the app, either by coding it or using the tools you are comfortable with, plus the patience to handle store review, updates, and bug reports.
• A developer account with the store, which usually has an annual or one-time fee.
• A way to reach the people with the problem that does not depend on store search. If you cannot name a few places these people already gather, you do not have a distribution plan yet.

Optional or nice to have:

• An existing audience or a following in the niche, which makes your first hundred installs far easier to get.
• Comfort with the numbers: install to trial to paid conversion, and retention over time.
• Design help for screenshots and store presence, since that is often what decides whether a browser installs.

If this list is starting to sound like running a small software business rather than shipping a hobby project, that is the right instinct. The mechanics are close to how to build a micro-SaaS, and reading that alongside this will fill in the recurring-revenue side.

What it costs#

The out-of-pocket cost of a solo app is usually modest, which is part of the appeal. The real cost is your time and attention.

Required costs:

• A store developer account fee to publish at all.
• Whatever you use to build the app. If you are coding it yourself, this can be close to free to start.
• A payment path for anything you sell, which for in-app purchases means the store's cut is built into every sale.

Optional or scaling costs:

• Any backend or hosting if your app talks to a server, which grows with usage.
• Third-party services the app depends on, for example an API you pay per use. If a paid service scales with your users, factor it into your pricing from the start.
• Ad spend, if you decide to buy installs, which is its own skill and easy to lose money on early.

The trap is spending money to acquire installs before you know whether installs turn into paying, retained users. Prove the app is useful to real people first, then think about paid growth. On pricing the thing itself, how to price a digital product covers the trade-offs that apply directly to a paid app or subscription.

How long it takes#

Longer than the "build an app in a weekend" pitch suggests, and the reason is everything downstream of the build. Writing the app might be the fast part. Getting it reviewed, getting the store listing to convert, getting the first real users, learning why people churn, and fixing onboarding is the slow part, and it is where the timeline actually lives.

What affects speed is mostly outside the code. How well you understand the problem, how directly you can reach the niche, and how sticky the app is all matter more than how polished it looks on launch day. An app that solves a painful recurring problem for people you can actually reach will find its footing faster than a beautiful app nobody can find. Do not attach a date to your first meaningful revenue. Attach it to milestones instead: first hundred real installs, first paying subscriber, first cohort that is still active a month later.

What beginners usually get wrong#

The biggest mistake is believing the store is a marketing channel. It is not. It is a storefront that rewards apps already getting installs. Publishing is the start of the distribution problem, not the end of it. If your entire plan is "list it and let the store bring users," you do not have a plan yet. Distribution beats product is the mindset shift here.

The second mistake is chasing downloads as the goal. Downloads feel like progress, but a person who installs and never reopens it is worth nothing. The apps that make money optimize for people who come back, not for a big install number in a screenshot.

The third mistake is reaching for ads because they seem effortless. Ad revenue only becomes real at large scale, and getting there as a solo developer is exactly the hard part. Many apps would earn far more asking a small, engaged group to pay than showing ads to a group too small to matter.

The fourth mistake is building the whole thing before talking to anyone. People fall in love with an idea, disappear for two months, launch to silence, and only then find out nobody wanted it. Validate the problem with real people first. Validate your idea before you build applies almost word for word to apps.

How I would start#

If I were building a solo app to actually make money, here is the sequence I would follow.

1. Pick a specific group of people I can reach, not just a category that sounds big. Somewhere I already have contacts or a community I can genuinely take part in.
2. Find a narrow, recurring problem that group has, ideally something they currently handle with an annoying workaround they would gladly drop.
3. Validate before building. Talk to a dozen of these people, confirm the problem is painful and recurring, and see whether they would pay to solve it.
4. Build the smallest version that solves just that one problem well on the platform those people actually use. No extra features.
5. Decide the money model up front based on the problem: a subscription if the value is ongoing, a one-time price if it is a tool they own, and treat ad-only as a last resort unless I have a clear path to large, frequent usage.
6. Get the store listing right, because the screenshots, title, and first reviews decide whether a browser installs. Ask early users for honest ratings.
7. Bring my own first users instead of waiting for the store. My existing audience, the communities in step one, and direct outreach come first.
8. Watch install to trial to paid, and watch how many people are still active after a week and a month. Fix the biggest leak, then repeat.

To get real about that "bring my own first users" step, our guide on getting your first customers lays out how to land the early handful who tell you whether any of this works.

What I would not do#

I would not build for two months in secret and hope the store surfaces it. I would not measure success by download count. I would not default to ads because they feel passive, when a small paying group would earn more. I would not spend money buying installs before I know that installs turn into retained, paying users. And I would not treat an app as passive income, because store rules change, operating systems update, users email, and the reviews need tending. It is a small business that happens to live on a phone.

The bottom line#

A solo mobile app can make money, but not because it is on the store. It makes money when it solves a narrow, recurring problem for a specific group and you can reach that group without relying on store search. The store takes its cut on everything sold inside it, discovery is brutal without ASO or outside traffic, and ad-only apps need a scale that is hard to reach alone. Downloads are the least important number in the chain. Whether the right people find it, try it, pay, and stay is what decides it, and every one of those steps is a distribution and product problem, not a coding one. If you want the recurring-revenue mechanics in more depth, how to build a micro-SaaS is the natural next read.