Subscription Pricing for Apps

The corner of the internet that I inhabit has been up in arms about yet another app, Ulysses, switching to a subscription-based pricing model. From the perspective of the developers trying to build a successful business this probably makes a lot of sense. The business analyst in me applauds them for finding an approach that will smooth revenue flows and help fund future development.

But changes like this can have unintended, or at least unforeseen, consequences. To my mind, the key question is how many users will switch over to this model? The developers may discover the addressable market shrinks considerably as their app will suddenly have a lot less appeal to hobbyists who are not earning revenue through their use of the app. They will probably sell subscriptions to authors and professional bloggers, but will that offset the losses? Did the developers truly understand the size of the market who would be willing to play for on-going use of the software?

User Centricity

I fear that developers are not taking a user-centric view to the subscription conundrum. Subscription revenue no doubt looks great in spreadsheet models with its recurring revenue. However, let’s apply the ‘job to be done’ approach to this issue, from the perspective of the end-user. I suggest that the job to be done is to provide a mechanism that will let me take notes that are ubiquitously available, and write occasional blog posts to be published to WordPress. Boiled down further, the job to be done is text editing and organising.

So my choice is not to subscribe to Ulysses or not. My choices range from open source text editors, to Apple Notes, to a word processor, or an alternative subscription-based product. If I didn’t want to blog, I could get by with a paper notebook and a pen.

It also creates a further issue in that it will reduce the likelihood that I will bounce between a number of apps. Up until now, I had decided to use Ulysses for blogging, Bear for notes, Scrivener for work reports, and DEVONThink for research and storage. I’ve paid for all of these apps.

With subscriptions becoming more prevalent, I will have to reduce my app consumption because I don’t want to be on the hook every month for apps that I may not use. I don’t want to reduce my personal free cash flow by paying a swathe of subscriptions, particularly for apps that are essentially supporting a hobby that generates no income. I will become more selective in my software choice. My overall long-term expenditure on software may decline. If many users have the same opinion, then the overall market activity is going to decline. The outcome becomes worse for all developers.

As I said earlier, unintended consequences.

My Choice

This whole subscription brouhaha has led me to review my note-taking writing structure, and I’ve decided to rely on another subscription app I pay for, Bear. Those developers charge less for a very similar product, and they were up-front about the software being subscription-based from the outset. In my opinion, Bear has a nicer look and better reflects Markdown styles. The only thing I lose is direct-to-blog publishing. However, I can pretty easily copy or export text in Markdown or HTML, both of which can be directly pasted into the WordPress CMS.

By choosing another subscription-based product, I demonstrate that I’m not entirely against recurring costs. But if I can have one recurring cost rather than two, then I’m all for that.

My situation is a real-world example of user-side app rationalisation that I think is likely to occur at scale, with the onset of subscription pricing.

3 Replies to “Subscription Pricing for Apps”

  1. Nice write up on the topic. I will be switching completely to Bear as well. It was nice to have the silos in a lot of ways to be able to switch between mindsets or focuses, but I have really grown to love Bear and it’s functionality across many disciplines.

  2. Interesting points, as developer who worked on Paw ( mostly the subscription part Paw for Teams) I wander how you feel about apps that chose to justify a subscription through the addition of a server component.

    From the developer perspective there is an issue in the big V paid upgrade model once the app becomes full enough so that any new feature you add both runs the risk of watering down the apps focused or is unnoticed and not considered a big feature. This leads to developers clustering work into big releases resulting in much requested features being release years after they se finished in the hope to bundle them with other features to make a big splash.

    1. Matthaus, thanks for chiming in, especially from your developer perspective.

      It is such a challenging problem. I think having a server-side element does make it easier to sell as the customer can see they are “paying for something tangible”, rather than just promises of “future development”.

      The continuous improvement cycle is also a reason given for much development. But then I subscribe to YNAB, who promised lots of ongoing improvements. I love that service and it gives me value, but in one year they have mainly delivered bug fixes (their errors, not user errors!) and after a year have just released full version mobile apps. So we had to wait a year of subscription time, and got a ‘big splash’ release after that time!

Leave a Reply

Your email address will not be published.