A solution to app store sustainability?

The rise of the app store model for software distribution has been an incredible boon for many independent developers, including the author of this post. It’s provided the exposure that solo devs were unable to get previously, and that – combined with easy payments – has enabled us to sell software in a way that just wasn’t practical before. It’s not only been a game-changer, it’s been a life-changer for many of us.

And yet, there are serious downsides. One that I’ve seen discussed a lot is the “race to the bottom” in pricing: that the default price for most paid apps is $0.99, the minimum that most app stores allow. This is a real issue, in that it devalues the software in the mind of the customer. But on a practical level, the size of the userbases involved has meant that it’s possible to make that up with volume, at least in theory. And the laws of supply and demand teach us that it may well be more profitable to price your product low – and sell a lot of them – than to price it high and only sell a few. So this isn’t a clear loss for devs.

A deeper issue, but one that I’ve seen less discussion of outside the developer community, is that of sustainability. As one well-respected dev said in a recent Google+ post, “Users expect the app they paid $2 for to be updated forever with every new OS release and with additional features, without any additional cost, forever.”

I hope I don’t need to explain the problem with this.

It can be OK as long as the market is expanding: a constant stream of new customers buying the app translates to an income stream for the dev. But the incremental cost of each new user is not zero: it costs the dev more time and effort to support 10,000 users than to support 100, in a number of ways. And if the number of users levels off, then the number of new purchases (and hence income for the dev) goes away, and the dev is left supporting the existing user base for free. Unless the app was extremely easy to develop in the first place (so there’s profit “left over”), was outrageously successful (which most of them aren’t), or has an extraordinarily low maintenance burden (hah!), it will inevitably turn into a losing proposition for the dev.

And although users may like the deal they’re getting now, if it’s unsustainable for developers, it will eventually be unsustainable for the whole app store.

So is there an answer to this, a way for modern apps to have a sustainable business model?

The conventional answer in the pre-app-store software world was to charge for updates. When you bought Windows 7, you had no expectation that you’d get updated to Windows 8 for free. That’s not how old-school software works, and everybody knows it. New versions come with a price tag, and while there might be a price break for existing users (or not), it’s still not free.

The first problem with applying this to mobile or web apps is that none of the major app stores support this pricing model. You can put a price on your app for the initial installation, but there’s no way to attach a price to an update. This is probably why that same G+ post mentioned above went on to say, “This is a fundamental problem that needs to be fixed by the platform providers.”

But if you dig a little deeper, I think you’ll find that it’s not that simple; such a “solution” wouldn’t actually solve the problem for indy devs. The reason is bug fixes.

Although I’d like to charge for updates, as an ethical developer I realize that it’s not OK to charge for bug fixes. These are essentially flaws in my product, and it’s my duty to fix them, to the best of my ability. If Google Play let me charge for updates to my apps, there’d inevitably be some users who would elect not to do it – users who are happy to remain on the older version. But additional bugs will inevitably turn up in these older versions, and since it’s my responsibility to fix them, this means that I end up maintaining two different versions of each app… then three versions, then four, another one each time I release a paid update.

Sure, eventually I can end-of-life old versions, but the time scale for that is measured in years – it limits the problem, but by no means eliminates it. I can also mitigate things somewhat by good use of source code management (so ideally bugs fixes happen once in common code, rather than being duplicated), but this is also an imperfect solution. The reality is, paid updates would actually multiply my software maintenance load. This really isn’t much of an improvement.

An alternative approach to the pay-for-each-update model is to create a new app on the store for each major version. So I’d release MyApp 1.0 for $0.99, then later create a new “app” on the store for MyApp 2.0, also $0.99. This has the advantage that it doesn’t require changes by the platform provider, but has a host of disadvantages:

  • It doesn’t help the bug-fix/multiple-version maintenance headache outlined above.
  • Every time you create a new app, you’re essentially starting from scratch on the app store. You lose your user base, your ratings & reviews, you have to fight your way up the listings again, and so on.
  • Your existing users need to be notified manually of the new version.
  • Migrating users from the old version to the new one is a headache. Settings need to be transferred, the user can easily end up with multiple versions on their device, etc.
  • There’s no way to give a discount to existing users.
  • Many users would scream bloody murder if you tried this (see the “pay once, get updates forever” expectation above)

In other words, this is pretty bad “solution”.

Another approach which is sometimes proposed is a subscription model. There are several variations to this, but they boil down to the same basic idea: charge your users an annual subscription fee for updates. While this is another model that isn’t explicitly supported by the app stores, they do support subscriptions, so it can be accomplished by the developer in their own code; essentially, by only making certain features available to users who have paid their subscription fee. This neatly avoids the version-multiplication problem we’ve had up until now: there’s only one version of the app out at any one time.

So I believe that this approach has some merit, but it also has some hurdles. One of the largest is the simple use of the word subscription: in the mind of the customer, a subscription is usually something that gets delivered either continuously, or quite frequently. Think of a music service (your tunes are delivered on-demand), or a magazine (which is delivered monthly). More generally, a subscription fee is something you pay for a service, not for a product.

And delivering frequent software updates as a service is a big ask for a solo developer, especially one who’s supporting multiple apps. Quite simply, I don’t have the capability to deliver frequent, major updates to all of my apps. Releasing a new version of every app, every month is fine if you’re Google, not so much if you’re one person working on your own.

“OK, so don’t support multiple apps”, I hear you say. That’s fine in theory, but it assumes that the single app I choose to support brings in enough income to support me. This is a big reason why I have multiple apps in the first place: because no single one would support me on its own. And once I put an app out there – especially with an update subscription – I’m making a commitment to support that app. I can’t just say, “This one’s not profitable enough, I’m pulling the plug on it.” I can’t afford that, and it’s not fair to the subscibers.

So subscriptions come with a lot of baggage – they’re an imperfect solution at best. Any other possibilities?

The last “standard” solution is in-app purchases (IAPs). Again, there are variations, but the basic proposal is to charge users piecemeal for significant new features. I develop something new for an existing app, it goes in as an IAP, and existing users need to pony up in order to use it. Sounds feasible, and again, it is an approach that is supported today by the app stores.

And it’s a reasonable model when one thinks in terms of the long-standing user: paid $2 for v1.0 of the app last year, pays another $1 for this year’s 2.0 features, and next year may pay another $1 for more new stuff in what I label as v3.0.

The problem comes after several years of this: new users (who are coming to the app for the first time) will find that the app they’ve just paid $2 for comes with many of its best features disabled, and they have to pay another $1 for each of them. They’ll rightly feel like they’re getting nickel-and-dimed here, and will likely voice this unhappiness in an app review. Bad news all around.

But maybe we’re getting close to a good solution here. I think we might be, and I have a proposal to make this work. It’s based on the IAP-for-upgrade model, but with a twist: when the next major update comes, the features from the last update get rolled into the “base” version of the app, for free.

Perhaps the best way to explain this is with a concrete example.
2014: I release the first version of my app, and set a price on it, say $2.
2015: I have a major update for the app, and release it as “Upgrade Pack 2015” for $1 as an IAP.
2016: I’ve created some more new features, and bundle them into “Upgrade Pack 2016”, for another $1. But when I release this, Upgrade Pack 2015 goes away, and its features get rolled into the main ($2) app.
2017+: Lather, rinse, repeat.

A better labeling system might be to not tie it to specific years, but to use semi-traditional version numbers instead. So the above release history would look like this (the years are just to tie it to the previous example):
2014: version 1.0 is released for $2
2015: new features go into “Version 1 Upgrade Pack” (v1UP), for an extra $1
2016: version 2.0 (containing the features from both version 1.0 and v1UP) is released to all users, no extra charge. Simultaneously, new features go out as v2UP for another $1.
2017: version 3.0 released (v2.0 + v2UP), as well as a new, $1, v3UP
 . . .

Here are the important points to this approach:

  • At each release, existing users can choose whether the new features are worth another buck to them.
  • If not, they’re free to stay on “the old version”, and will get bug fixes all the same.
  • There’s never more than one code base to maintain; a single binary contains all features, and just has some of them paywalled behind an IAP.
  • At no point is there more than one Upgrade Pack available. So new users never get the nickel-and-dime feeling: there’s just the main app, plus one optional Upgrade Pack.

Looking at it another way, users are paying for “early access” to the features in each Upgrade Pack: if they want to wait, they will get them eventually, when the next UP is released.

About the only downside I see is that you’d probably need to explain this to the users as simply as possible, because it is a bit unorthodox. But that’s probably doable. [And with luck, it could even catch on and become orthodox. Call it the vnUP approach.]

Oh, and IAPs themselves are kind of a PITA, and need to be re-implemented for each app store you’re selling on (Google, Amazon, Apple, Samsung, etc.). But that’s one-time pain, and this work can possibly be re-used between projects.

One nice upside is that this can be layered onto a mature app, one that’s already in the wild with an existing user base. As long as you roll out your first UP along with some other, free bug fixes and minor enhancements, PR shouldn’t be too problematic. Then your pump is primed to keep the ball rolling with later versions.

But the big upside is that the app store business actually becomes sustainable. If a dev keeps adding new features, she has a legitimate opportunity to monetize her existing users on an ongoing basis. Everyone’s happy: the developer’s making a living, and the users get continuing updates, for a price that’s still very reasonable – or even for free, if they’re willing to wait. It’s a win for everyone.

Users: what do you think? A fair compromise?

Developers: are you with me?

Advertisements