Making Money With a Mobile App: Monetization Strategy

Consider a mobile app that is being actively developed. We are talking about a "live" app, one that has a team of software engineers continuously working on new features and regularly releasing app updates.

For example, it could be an app with educational games for kids. Or it could be an app that helps people to find a team for a friendly soccer game at a nearby field. Or maybe it's an app that helps people track their sugar level and insulin injections.

The company building the app needs to eventually make some profit, so they need a way to get paid. How exactly is it going to work?

Paid App or Free App?

It can be a paid app. The user pays a fixed amount (e.g. $5) when downloading it from the app store. For the user it is the simplest approach. But for most companies it is a non-starter, because their competitors have free options available.

There can be a free "light" version with reduced set of features along with the full paid app. The users can try the free app first, and then purchase the paid one to get more functions. However, having two versions adds complexity and may be confusing for the users. With two separate apps, upgrading requires the user to uninstall the free app and subsequently download and install the paid one.

Luckily, it can be just one free app with paid options coming later as in-app purchases. This way the upgrade flow is seamless - users can download and try the app, then, after they get familiar with it and like it enough they can make a payment. We will consider this option as the baseline from now on.

How exactly should the paid features be unlocked?

One-Time Payment

The simplest approach: one-time payment (say, $5) unlocks all the features of the app, forever. This works very well for those apps that are no longer updated. And not so good for an actively developed app with new features being added.

For example, if the app contained three learning games when it was first released and several more games were added to the app over the next year. Or maybe new features like tournaments or even leagues were added to the soccer app.

With one-time payment users get all the future updates for free. Maybe that's ok. But maybe the company would like to be able to earn some extra income for the newly added features.

Subscription

Time-based subscription is a more flexible option. If the subscription cost is set to $3/month (or $30/year), then the revenue from long-term users will come steadily, along with the app updates coming to users.

Of course, the company would like to have a renewable subscription, so the engineers need to enable "recurring billing". Users should be able to manage their subscription, and have an option to unsubscribe. The app needs to be able to "downgrade" and lock away paid features if the subscription expires.

Some users might be willing to pay more for added convenience. So the company may want to offer several levels of subscriptions, such as "standard" and "advanced". The free option can then be considered a special case of subscription with zero cost.

Extra Paid Options

The app may have "premium" options. It could be a feature that addresses a particular problem. It might be needed only by a fraction of users, but for those who need it, it is highly valuable.

For example, in an app with learning games for children, if two kids share the same device, the app may have a "profile switch" feature so that the progress of each player can be tracked separately. Or if the blood sugar tracking app has support for an insulin pump, it could be a life-changing option for some users.

An extra option, in order to be enabled, could have a one-time cost (unlock the feature forever for a fixed fee) or a subscription cost (like an extra $2/month).

Making Users Pay

Besides coding, implementing a successful subscription model requires some social engineering. The idea is to "try before you buy", so in the best case users become familiar with the app, and then decide to purchase a subscription. And naturally, some people will use the free app but never pay for a subscription.

Sure enough the company would not be happy if the users can freeload and keep using the free version of the app and never paying. So some limits need to be set.

How to balance free and paid parts of the app? To what extent is "freeloading" acceptable? That would be an important decision for the company to make.

Maybe having many non-paying users is ok, and even desirable for the company, as having a large user base helps to promote the app via word of mouth. After all, having even only 1% of paying users out of one million, is still 10k paying customers. So the company will treat the free app as the main product, while the paid options will be, well, optional.

Or maybe the company will only provide a limited demo/trial, with the most of users eventually becoming paying customers. In this case, the paid app is the main product, while the free demo is a cut-down limited version.

Finding the right balance between free and paid options will take some trial and error to get right. So the engineering team needs to be ready to do some experimenting and collect and analyze some behavioral data.

Evolution of Billing

A successful app will most probably stay in active development for the most of its lifecycle. Besides adding new features, the engineering team has to keep up with new technologies, new devices and new regulations. The subscription model will be evolving along with the app.

• Perhaps the app starts with a simple one-time payment option. Then, in six months, the company switches to a subscription model. Of course, users who previously bought the app with a one-time payment will get a (hidden) lifetime subscription.
• The company may want to give out a few copies of the app for free as a promotion, so there needs to be a way to enable paid subscription for a certain user without a payment.
• Maybe a year later the subscription cost is changed a bit. Then the users on active subscription will have the old price till the end of their billing cycle, while the new users will have to pay the new subscription price.

Over time the billing logic becomes more complex with various special cases being added to support the growing number of use cases. Some engineering effort will be needed to keep the complexity under control and make sure the users understand how the subscription works.

Above and Beyond

In-app purchases, while very convenient for the users, may be less convenient for a company owning the app. Both Apple and Google require using their built-in payment service for in-app purchases, and they will take a 30% cut. Also, their terms and conditions have a lot of limitations on what could be sold via in-app purchases.

Let's zoom out. Perhaps the company does not "sell an app", but it provides some service. The app is a convenient gateway into the service. And the service is available not only via the app, but also via some other means (like a website).

For example, there may be a website for a kid learning games app with a parent portal to track their children's progress, so it would be natural to accept a subscription payment on the website. Or, for a soccer app, the fee for playing a game could be collected at the sports center's physical terminal.

As long as the company provides a genuinely useful service for their users, with the help of an app, there are many ways for the company to get paid.