Site menu How much for your app?
e-mail icon
Site menu

How much for your app?

e-mail icon


This article expresses the author's opinion at the time of writing. There are no guarantees of correctness, originality or current relevance. Copying the whole article is forbidden. Transcription of selected parts is allowed provided that author and this source are mentioned.

There is a pervasive culture where "everything's for free" regarding software and Internet services. This is a major challenge when evaluating how much a product or service is worth, be it a s simple mobile app, be it a culture-shaping service like Twitter. By the way, Twitter is for sale. How much can be worth a service that nobody pays for using? Would any user accept paying for it?

"Every man has his price", and every asset, be it a product or a service, also has a value, even if it is offered for free. It's just not that simple to determine this value.

Typically, "free" apps and services are financed by advertisements ("ads"). Nobody really likes ads, but if even Google found its main revenue source in ads, it means that is really difficult to find another means to keep the lights on. In Android platform, a prosaic issue is that many users in developing countries are willing to pay but they don't have an international credit card.

The best would be to convince the user that a "free" app is actually being paid in installments, since the ads consume energy, data, and occupy a lot of the most expensive square foot of the world — the screen of a cell phone. If even the politicians, whose stock of the trade is persuasion, fail to convince people to endorse proposals that are obviously right and good, we developers don't have any chance.

Another minor problem, but still a relevant one, is the business model for paid apps. If the user is convinced to pay for an app, he just pays once. A remarkable characteristic of mobile platforms is that they are a moving target. Apps need frequent updates, at least once every major update of the platform. The single payment does not reflect this continuous maintenance work that an app takes to stay usable.

App stores still don't support the notion of paid updates (Firefox OS was an honorable exception). Apple added "subscriptions" recently, but made clear that it is for apps that have continuously-updated contents; it was not conceived to reward the invisible work that keeps "unchanging" apps working. An alternative is to launch a "new" app and discontinue the older in order to force a re-buy. And prepare yourself to hear many complaints.

WhatsApp implements a model that is almost perfect: the app itself is free, there are no ads, the first year using the service is free, and it bills $2/year after this time (billed thorugh in-app purchase). But WhatsApp is Whatsapp, it is almost a public utility these days. How many other apps the user could be convinced to pay a yearly tax for, even if small?

Os apps "gratuitos" que mostram propaganda têm essa vantagem marginal para nós desenvolvedores: eles geram renda continuamente, mês após mês, ainda que a renda por usuário seja minúscula. É preciso ter muitíssimos usuários para que o rendimento com ads seja economicamente relevante.

A typical method to solve this free/paid app dichotomy is to offer two versions, one for free (with ads) and another is paid. It can be two separate apps, or the same app that is "activated" with in-app purchase. The method does not matter; the question is: which is the fair price for the paid app? How to maximize profits and still be fair with both types of user?

We can use some basic financial math to find some objective figures, and make some decisions based upon them.

For example, suppose a free app that earns $24.000/year in ads, has 100 thousand active users (will talk later how to find this number) and let's use a 25% rate of return (will talk about this later, too). The calculation is:

(24,000 / 100,000) / 0.25

= 0.96

We use the formula for "present value of perpetuity", and find out that every user that the app can conquer is worth $0,96, almost $1. It is not glamourous to reduce the value of an app, or of a user, to the volume of ads that they can absorb, but c'est la vie.

With this figure in mind, we can say that the paid version should be priced above $1, so it is actually profitable to sell an ad-free version. On the other hand, the price cannot be too high, otherwise you are flaying the buyer. Offering extra features in premium version (on top of ads removal) is a bounty that helps to justify a higher price.

An additional inference that the formula above gives us, is: if we have 100 thousand users and every user is worth $1, our app is "worth" $100,000 as a whole. That would be the fair price if the app was sold to another company.

It feels funny that an asset that generates a mere $2,000/month can be worth $100,000, but if you know any other investment that generates a sustained revenue of 2%/month or 25%/year, please tell me!

This is the kind of reasoning that a software developer should make when quoting a price — how many thousands (or millions) of people the project will reach, how much money and hours of work the software will save, etc. Looking at this angle, the figures get big very fast, and it is just fair to plead a piece of the action.

The thing gets even more interesting when we take the rate of growth into account. If your user base is consistently growing, we can incorporate this to the perpetuity formula. Suppose the same numbers, but with a growth rate of 10%/year:

24,000 / ( 0.25 - 0.10 )

= 160,000

The sale value for the app jumped from $100,000 to $160,000.

By the way, the formula above is called "Gordon model". It is a bit simplistic, because nothing actually grows forever in a fixed rate, but it does generate an initial number to start negotiating. A major problem of the Gordon model is to produce enormous numbers when growth rate nears the return rate. When this happens, it is necessary to employ more sophisticated models, but this fact also explains why startups and even big companies pursue a big growth rate so badly.

Well, the formula itself is simple, but finding the factors may not be. The revenue figure is the easiest, just make an average of monthly payments. On the other hand, determine the number of active users and the return rate is more complciated. Knowing the growth rate depends on knowing the evolution of active users over time.

Active users

Nowadays, every app embeds "Analytics" — remote monitoring of how the users are using the app. It is compulsory to do that, because it is the only way to find out how many active users you have, and how much "face time" they are spending on your product. The number of app installs does not mean much, in particular when it is a free app.

It is a bit disturbing that everything you do in your phone, in your video-game, in your cable TV, etc. is being continuously monitored and reported to the mother ship (they say that information is anonymised — who knows?). It is equally disturbing to do the same, but...

Google offers the Firebase service to analyse apps, which is very easy to add, and you don't even need to monitor most event, since Firebase Analytics already tallies the most typical events (open app, put app in background, etc.) For some time now, Apple automatically monitors and reports some metrics on your apps, without any change in the software.

The metric that defines "active user" may vary. It can be the daily users of your app, or the monthly users. Or users that spent a minimum of x minutes of face time on the app in the last month. When doing a pitch for investors or buyers, it is very important to have all these numbers in mind, because they are the first things that they will question. The rates of growth for each metric are also important.

If you don't use Analytics, a metric (that is distant second option in terms of quality, but better than nothing) is to determine how many users are using the latest version of the app. If the user updated the app, he didn't remove it after the first trial, and there is a good chance that it is being actually being used.

Rate of return

The third ingredient of the evaluation of an app, is the rate of return. As said before (briefly), the rate of return represents the dividends of an investment. For example, a capital of $100,000 put into a 25% investment will earn a montly income of around $2,000, forever. We employed this formula in reverse: given the income (that we know), find the value of capital.

As also said before, there are not many investments in the market that pay 25%/year. Savings accounts pay 6%/year (in Brazil). If you are offered a return of 25%, it is certainly a very risky investment. In fact, the "capital value" of an app is under permanent risk: the app may be copied, cloned, imitated, banned from the store, banned from ads service, or the users may simply lose interest.

Besides, a big part of the rate of return is not profit! It needs to embed the cost of work needed to keep the app working, and even to improve the app over time to keep users interested (which is needed to keep the growth rate that was considered in the evaluation). A rate of 25%/year may represent just 15% of dividends — the other 10% go to cover expenses.

I used a 25% return rate as initial basis. But if you actually try to sell your app (or your site) the typical proposal will be something between 2 or 3 times the proven yearly income of the product, which translates to a 50% or 33% rate of return, respectively. Since the income is a hard value, and the number of active users can also be determined objectively, the actual negotiation happens over the rate of return.

As mentioned before, the growth rate has enormous influence over the value, because it discounts the return rate. Even with a return rate of 50% (almost a "steal"), a 35% growth rate reduces it to 15%, which means an evaluation of six times the yearly income.

e-mail icon