Tag Archives: economics

Software upgrade economics: some real numbers

My seating planner software, PerfectTablePlan, is now at v7. Major upgrades are paid (discounted 60% compared to new licences), which means I have done 6 cycles of paid upgrades. I was curious about how long it took people to upgrade, and what percentage of sales are upgrades. So I took a few minutes to crunch the numbers direct from my licence key database, using my data wrangling software, Easy Data Transform.

Here are the number of upgrade licences I sold for each week after the major upgrade. Each release is in a different colour. The values are normalised so that the peak is the same height for each release:

Upgrade licences sold per week after a major upgrade, across 6 upgrades

That looks rather messy. So here it is with the values for the 6 upgrades summed:

Upgrade licences sold per week after a major upgrade, summed across 6 upgrades.

There is a long tail of upgrades. Even when the gap between releases was 6 years, I was still getting regular upgrade purchases.

With the v5 to v6 upgrade it took:

  • 23 weeks before 50% of the upgrades were sold.
  • 74 weeks before 75% of the upgrades were sold.

So it isn’t a neat exponential decay.

This table shows how many users actually upgraded from v5 to v6:

EditionUpgraded
Home edition12%
Advanced edition31%
Professional edition45%

Most of the Home edition purchasers are buying a licence for a one-off event, such as a wedding. So it is not surprising that they are much less likely to upgrade. But I think it also shows that less price-sensitive customers are significantly more likely to upgrade, even when the upgrade is more expensive.

This graph show the percentage of PerfectTablePlan licences sold each month that were upgrades, over the 20 year life of the product:

Percentage of sales that are upgrades per month.

You can see that upgrades are still increasingly important over time. Upgrades are worth less than new sales, so selling 80% upgrade licences in a month doesn’t mean 80% of revenue is from upgrades. However, upgrades are still an increasingly significant source of revenue for us. I’m glad I never agree to free upgrades for life.

Could I have made more sales with more frequent major upgrades? Definitely. But I was also working on other projects. And I am not out to squeeze every last penny out of my loyal customers.

Could I have made more sales with a subscription model? Possibly. But subscriptions weren’t really a thing for desktop software, when I started 20 years ago. And I never felt like making a major change to a licensing model that had worked well for me, so far.

iPhone App store economics

If you believe all the hype about iPhone apps, you can just hammer out an App in a few weeks, let that nice Mr Jobs take care of all that sordid marketing for you and then sit back to collect a big cheque every month. However the numbers in a recent sobering post about the economics of paid iPhone apps tell a rather different story:

  • average annual income for a paid iPhone app (after the App store 30%): $3,050
  • median annual income for a paid iPhone app (after the App store 30%): $682

The numbers are based on various published data from Apple and other sources, plus a few assumptions. I haven’t gone through the numbers and the analysis with a fine tooth comb, but I can’t say I am surprised.

The disconnect between the hype and the reality is so large because Apple (understandably) only want to tell developers about the success stories. The media and the public seem quite happy to go along with this because it makes a more interesting story. But when there are 225,000 apps shouting for attention, only one way to access them via a notoriously dictatorial third party and $5 is considered expensive, it is likely that the majority of developers will do badly. Hence the median is so much worse than the mean. Before you write your iPhone App I think you should ask yourself if it has got a realistic shot at making the top 10 in its App store category. If not, don’t give up the day job just yet.

Further reading:

The Sparrow problem

How to Evaluate a (paid) iPhone App Idea