Nobody Pays You to Recommend an App. Here Is Where Mobile Money Actually Sits

Every few months a client asks a version of the same question: if we build an app, can we make money recommending other apps inside it?

The short answer is no, and the reason is worth understanding, because it tells you where mobile revenue actually lives.

The affiliate route is closed

Apple ran an affiliate programme that paid a commission on App Store purchases. It was wound back, then closed for apps entirely. Google Play never offered an equivalent.

So the model people imagine — write about apps, link to the store, collect a percentage — has no plumbing behind it. The stores have no interest in paying for traffic they already own. When somebody is searching the App Store, they are already inside Apple’s funnel.

This matters beyond affiliate schemes, because it is the same reason several other plans fail: the stores are not a partner, they are a landlord. They take 15-30% depending on your size and program status, they own the customer relationship, and they change the terms unilaterally. Any business model that depends on the store’s goodwill is renting.

Where the money actually is

Three places, in increasing order of how much control you keep.

1. Subscriptions inside your own app

The most direct. You charge, the store takes its cut, you keep the rest. Boring, and by far the most reliable.

What surprises people is how much of the work is not the paywall. It is:

• Entitlement — knowing, on any device at any moment, whether this user has paid. Harder than it sounds once someone subscribes on an iPhone and opens the app on an iPad.
• Receipt validation — verifying the purchase server-side, because a client-side check is trivially bypassed.
• Renewals, grace periods, billing retry — a card declines, the store retries for days, and your app has to decide what the user sees meanwhile.
• Refunds and chargebacks arriving asynchronously, sometimes weeks later.

This is why services like RevenueCat exist and why most teams should use one rather than build it. Worth noting RevenueCat states plainly it has no built-in affiliate feature — a useful reminder that even the subscription layer is not an affiliate channel.

2. Being the software layer somebody else pays for

The B2B version, and often the better business in Australia where consumer scale is limited by a population smaller than greater Tokyo.

An app that a clinic pays for per practitioner, or a trades business pays for per field tech, is not competing for consumer attention. It is competing on whether it saves someone an hour. That is a much easier sale and a much stickier one, and it is why most of the app work we do is B2B rather than consumer.

3. The service layer around the app

Integration, data migration, compliance work, ongoing development. Unglamorous, and it is what actually funds most Australian app businesses.

The Australian numbers problem

Consumer app economics assume scale. If your addressable market is Australian, you are working with roughly 27 million people, of whom some fraction have the problem, of whom some fraction will pay.

Run that arithmetic before you build a consumer subscription app. It frequently produces a number that cannot support a team — and it is far cheaper to find that out on a whiteboard than after a build.

The same arithmetic is why the B2B route wins here so often. A hundred businesses paying $200 a month is a real business. A hundred thousand consumers paying $2.99 is a much harder one to reach from Sydney.

What to check before committing

1. Who is the payer, and is it the user? If they differ, you are B2B, and your app needs admin, seats and reporting — not viral loops.
2. What is your cut after the store takes theirs? Model 30%, then confirm whether you qualify for the small-business rate.
3. What happens when a subscription lapses? Read-only, locked, or degraded? Decide before launch; retrofitting it is painful.
4. Where does entitlement live? If the answer is “in the app”, that is a bug waiting to be found.
5. Does the business survive if the store changes terms? If not, that is the actual risk, not the build cost.

The uncomfortable version

Most consumer app ideas brought to us do not have a business model. They have a feature and an assumption that scale will arrive.

The ones that work tend to be unglamorous: a booking tool for a specific trade, a compliance recorder for a specific regulation, an ordering app for a business that already has customers. They have a payer identified on day one.

We would rather say that at the quoting stage than eighteen months later.

If you are working through this

We build mobile apps for Australian businesses, and a fair amount of that work starts with talking somebody out of the version they arrived with. If you want a straight read on whether your idea has a payer, tell us what you are trying to build — including if the honest answer is that it should be a web app, or nothing at all.