Coming soon: progress graphs

I’m currently working on adding progress graphs to the app. As you can see below, it’s pretty simple at the moment but possibly useful.

graph

Measuring progress with a language is always a bit of an arbitrary task. It’s impossible to quantify exactly how fluent you are and how effective this week’s work was. My approach is not to worry about this too much. Internally, the app awards you points for getting questions right, and more points for doing harder tasks (even looking at flash cards gains you a small number of points). The idea is that you can tell at a glance whether you’ve been working consistently through the week.

Ideas for how to improve this are always welcome. As usual, email feedback@sharplanguages.com.

How to price your mobile app?

As some of you have probably seen, I’ve recently added payments to my app for the first time. This raises an important question, to which I don’t have a good answer: how do I decide what to charge for it?

I’ll talk more in a later post about how I came up with the particular choices I made for my app, but right now I want to talk about some of more general issues with pricing mobile content.

You can take one of three choices when choosing a price, which I’ve heard summarised as the good, the bad and the ugly:

  • the good: price the product according to what it is worth for the person who uses it.
  • the bad: price according to how much it cost to produce.
  • the ugly: price so as to undercut your competitor (which can often lead to price wars).

If I price my app according to what it cost to produce (i.e. the “bad” way), I have a problem: on the open market, my time (and the time of any developer) is pretty expensive. If I charge by the hour at the rate a bank or a large technology company would pay me, then the app would cost each user thousands of dollars.

But of course, you spotted the problem there: I said “each user”. If there are lots of users, it doesn’t cost me any more than if there are only a few. And if there are many thousands of users, then each might only have to pay a dollar or so. Indeed, if I can persuade millions of users to buy, then each might have to pay a fraction of a cent. And of course, the lower the price is the more people will buy!

This line of reasoning leads developers down the path of the “ugly” solution: trying to undercut other producers in the same market to get the attention of users. Look at flashlight apps: there are hundreds or thousands of them, and they all offer the same benefit. Users don’t want to pay more than they have to, so the apps all end up  being free.

This isn’t how it works in economics textbooks. In theory, as the price gets driven down producers choose to do something else with their time, until eventually there’s only one producer left (the cheapest). This producer gets the whole of the market, but the remaining producers get to spend their time on something more valuable (perhaps creating a different product, or just enjoying time with their friends and family) than creating endless copies of the same thing.

There are lots of reasons why this doesn’t work in the mobile app market, but one particular one is that prices can’t go arbitrarily low. Once you price much below a dollar, the cost of doing the transaction (mostly paid to the credit card provider) starts to take up most of the price and leave less and less to pay the producer anyway. So instead of seeing a flashlight app for 3 cents that manages to win business away from a 4-cent app (or a 3-cent app with slightly fewer features), you see hundreds of free apps with no way to differentiate themselves.

I’ve lots more to say on this topic, including on what the “good” pricing method might have to say about mobile apps, but I’ll leave it there for  now.