How Much Can You Earn From App Development?

Two questions sit inside the phrase app developer earnings, and they have completely different answers. What you get paid to build apps for other people is steady, negotiable and capped by the number of hours in your week. What an app earns once it's live is slow, uneven, and it almost never arrives on the timetable the founder had in mind when they signed off the budget.

Money from an app arrives later than anyone plans for, and it arrives in small amounts, repeatedly.

We work on the strategy, research and design side of product, which means we see both sides of this. We've sat with a client who paid about £15,000 to rewrite a feature they'd already paid for once. We've watched a product priced to recover its production cost sell almost nothing. And we've seen a perfectly good app die in Apple's review queue for reasons that had nothing to do with the app.

So this is an honest account of where the money comes from, what gets taken out of it before it reaches you, and how long the whole thing takes. Some of it's cheerful. Quite a lot of it isn't.

What App Developers Earn on a Salary

Salary bands for app developers shift so much by city, platform and company size that any single number you read is already out of date. The more useful question is what moves someone from the bottom of a band to the top, and it's rarely typing speed.

We worked on a dating app built around verified profiles and keeping bots out. The client chose to skip discovery on the messaging component and put everything into onboarding instead. What got built was a generic messaging feature, and it allowed automated messages and fake messages, which contradicted every bit of verification work the onboarding did. The whole section had to be rewritten. That was roughly £15,000 of extra budget and two months of extra work.

The developer who spots that contradiction in a planning conversation is worth a great deal more than the one who builds the generic version quickly. That's the gap pay scales are trying to measure.

What drives app developer earnings

• Depth on one platform rather than a shallow pass at three
• Owning releases, store accounts and review responses, not just code
• Payments, identity and anything with compliance attached
• Being able to say what a feature costs before anyone builds it

Freelance and Contract Day Rates

A day rate is really a price for risk. The more risk you take off the client's hands, the higher it goes, and the clients who pay the most are the ones who've been burned by a cheap rate before.

We worked on a football-focused social media app where the client wanted a streamlined first release, MVP style, but carried expectations of a premium finished experience. The budget and the expectation didn't match. A lower budget means less flexibility and a tight focus on getting something launchable, and this client wanted the lower budget without any of the limitations attached to it. We had several conversations trying to bring the two into line. The product did get finished, with compromises on features, because the client put money into areas we'd flagged as lower priority.

Price the conversations into your rate. Scope defence, expectation setting and saying no to a feature are the work, and freelancers who treat them as unpaid overhead end up subsidising the project.

Contract roles through an agency smooth out the gaps between projects and pay less per day for that privilege. Direct freelance work pays more per day and leaves you carrying the sales, the admin and the quiet months.

The Skills and Sectors That Pay More

We worked on a logistics platform for transport-based deliveries and removals, and it had two parts. Customers used a web product, because the use case didn't warrant a mobile app at all. Drivers got a mobile app. The drivers were third parties, similar to the Uber model, so we needed a way of confirming a delivery had actually happened that was fair to both sides. We landed on swappable codes and QR codes that get scanned, producing a double confirmation from the customer and the driver together.

On a separate gig economy product we put an escrow service in place, so the money sits in advance and gets released after a double sign-off. The funds are proven to exist before anyone starts work.

The work that pays most is the work where money changes hands and somebody has to prove it happened.

Neither of those is a hard interface problem. Both are trust problems with money attached, and that's the category where rates climb. Marketplaces, subscriptions, anything with payouts, disputes or identity checks in it. Lifestyle categories pay well when they share that shape, so a wellness platform taking practitioner bookings sits in different territory to a fashion brand's catalogue app, even though the screens look similar.

Agency, In-House or Solo: How the Money Differs

The three routes pay differently because they load the risk differently, and that's easier to see side by side.

Solo numbers get shared loudly when they're good and quietly when they aren't. Sebastian Roehl published a year wrap on X, 2025 reporting $602K in cumulative lifetime revenue across two apps and around $28K in monthly recurring revenue, self-reported, with over 560K downloads behind it. That's a real outcome and it's also the visible end of a very long tail, built over years rather than a quarter.

Agency work pays you to be wrong at someone else's expense, which is worth more than people admit when they're comparing it to a product dream.

Do Apps Earn Per Download?

No. Apps don't earn per download unless the app itself costs money to download, and almost none of them do. Most of the store is free at the point of install, with somewhere around 73% of App Store apps and games listed as free according to International Business Times. A download is permission to start a relationship, and nothing more.

That's the single most expensive misunderstanding we meet. Founders bring us download forecasts and ask what the revenue will be, when the number that matters sits two or three steps further down. On a niche trading platform we worked on, one of the inputs we had to model was the conversion rate between a download and an active, revenue-generating user, because the gap between those two populations was where the whole business case lived.

Ads pay per impression. Subscriptions pay monthly, for as long as somebody stays. Commission pays per transaction. Paid downloads pay once, badly, to a small number of people.

Before you forecast anything, write down what a single user has to do for you to get paid. If the answer is "install it", you don't have a revenue model yet.

Pricing Your Own App: Why Production Cost Is the Wrong Anchor

A client came to us with a backing track app for musicians. They came from the music world and knew precisely what the recordings had cost to produce. We'd looked at the market and found it was niche, spanning professional musicians and casual players at home, which pointed clearly at a low price and mass adoption. Our advice to them was blunt. As Simon put it, "nobody will actually pay what you think it should be worth and instead we should be looking at this as purely as a volume product".

They disagreed. The price had to reflect the production value of the content, and they wanted the production cost back within weeks. Sales came in low, exactly as we'd expected.

The buyer can't see your cost base. They can't see the studio time, the session players, the eighteen months of development. All they see is a price next to other prices, and they judge it against those. Anchoring to what it cost you to make is the one input the customer has no access to, and it quietly removes every other option from the table, including the lower introductory price that gets a niche product moving in the first place.

Earning From Transactions, Not Downloads

Transaction revenue changes the shape of the whole product, because you get paid when something completes rather than when something installs. On the logistics platform, the swapped codes and QR scans existed so both parties confirmed the delivery, and that confirmation is the moment the business earns. On the separate gig economy product, escrow held the money up front and released it after a double sign-off, so the platform took its cut from a transaction that had already been funded.

You only get paid when the user gets what they came for, which is a healthier kind of pressure.

It's harder to model and better to own. Subscriptions decay quietly whether people use the product or not, so the revenue flatters you for a while and then falls off a cliff. Commission tells you the truth every month.

The design consequence is that disputes, refunds and proof of completion stop being edge cases. They become the core of the product, and they need the same attention as onboarding. The dating app we mentioned earlier is the same lesson in a different sector, where the part nobody wanted to examine turned out to be load-bearing.

Forecasting Revenue Beyond Year One

The niche trading platform was the hardest forecast we've worked on, because revenue came from commission on trades rather than a flat fee. A flat fee model is arithmetic. Commission is a chain of assumptions, and each one has to be defensible to an investor reading it.

The model needed six things before it said anything useful.

1. User acquisition at the start of each month
2. Monthly churn against that base
3. Transactions per user across their lifetime on the product
4. The conversion rate from download to active, paying user
5. Commission rate, with platform fees taken out
6. An allowance for dispute amounts

With those in place we mapped one, three and five year projections that held up under questioning. Year one was the least interesting part of it. The value of the exercise was watching which assumption the whole thing hung on, because that tells you what to fix first.

Later years come from monetisation rather than fresh installs. Global in-app purchase and paid app revenue hit $167 billion in 2025, up 10.6% year on year, while downloads grew just 0.8% according to Sensor Tower, 2026. Growth is coming from people spending more, not more people arriving.

The Costs That Come Out of Your Earnings

Whatever the store reports, you don't receive it. In-app purchases hand 15-30% straight to Apple or Google, per SplitMetrics, with 15% applying to smaller developers under the small business programmes and to subscription renewals after the first year, and 30% being the headline rate otherwise. Build your forecast on gross revenue and you're out by nearly a third before anything else happens.

Then there's everything that keeps running. Developer accounts, hosting, payment processing, customer support, and a new operating system every year that breaks something you'd forgotten about.

Multiple surfaces multiply this. The logistics platform had a web product for customers and a separate mobile app for drivers, which was the right call for the use case, and it also meant two codebases to maintain for the life of the product. Every change to the confirmation flow had to land in both places and stay consistent.

Put a maintenance line in the business case from day one, sized as a yearly percentage of the build. A product with no maintenance budget degrades until people stop using it, and then the revenue question answers itself.

Where Client Projects Lose Money

Scope creep has a price and we can give you the shape of it. On a sports club app we worked on, the product should have reached market within three to four months. After twelve to fourteen months it still hadn't launched. The budget almost doubled over that time, and every bit of it was forecast and advised against as it was happening.

Simon's summary of that project is short. "Another example where listening to us and working with the process is so critical."

What goes wrong is almost always the same decision in different clothes. The client wants everything in the first release, resists the idea of an incremental launch, and treats the staged approach as a watered-down version of the real plan. So the launch date moves, the feature list grows to fill the new time, and the date moves again.

The football social app lost money in a quieter way. The budget was real enough, it just went to the features the client cared about rather than the ones the product needed, and the compromises showed up at the end where they're most expensive to fix.

What Apple and Google Can Do to Your Income

We worked on a currency exchange app that Apple rejected repeatedly, despite it meeting every compliance requirement they'd stated. Each time we fixed the objection they'd raised, a new objection appeared. Eventually they cited the risk of money laundering and criminal use. When the product pivoted to an in-person model, we capped transactions at roughly €100 to €150 so large sums couldn't move through it. Apple rejected it again anyway. The client ran out of budget and walked away from the product.

Apple Pay and other payment services launched not long afterwards. We think the two were connected.

Apple can end a product's life without ever explaining why, and no amount of compliance work changes that.

Store account control matters for the same reason. On a social football product we worked on, the client held the App Store Connect Account Holder role because the account was registered in their name. We had admin access to most of it and set up three testing groups, one internal for us, one for the client, one external QA group for their testers. Near launch the client started sending uploaded builds directly to whichever group they fancied, which caused problems we had no way to stop.

How Long Before the Money Arrives

Longer than the plan says. Discovery and design take weeks, the build takes months, review takes days that feel like weeks, and then the app is live and almost nothing happens for a while. The stores pay out monthly, on a delay, once you clear a minimum balance, so even a good first month doesn't reach your bank account that month.

The honest version is that a consumer product is a long-term investment, and the revenue compounds through retention and volume rather than arriving in a lump. The music app client wanted the production cost back within weeks. The sports club app spent twelve to fourteen months not earning anything at all, because nothing shipped.

Shipping something small and real is what shortens the wait. A first release that earns a little tells you which of your assumptions were wrong while you still have budget to act on it.

Client work pays much sooner, which is why so many people fund a product with contract income. That's a sensible plan as long as you've been honest with yourself about how many months of it you're signing up for.

Conclusion

App developer earnings come down to which risk you're prepared to hold. Take a salary and you get paid every month while someone else worries about whether the product works. Go freelance and you get a better daily rate for carrying the gaps. Build your own thing and you hold all of it, with the payoff arriving years later if the retention holds up.

On the product side, the numbers that actually move are the ones after the download. What someone does, how often, and what share of it reaches you after Apple and Google take theirs. The projects we've seen lose the most money lost it early, in decisions about scope, pricing and what to skip, long before anything reached a store.

If you're sizing up a product and want a realistic view of what it earns, what it costs to keep alive, and where the forecast is likely to be wrong, we're happy to look at it with you. Let's talk about your app's numbers.

Frequently Asked Questions