Skip to content

Instantly share code, notes, and snippets.

@jmduke
Created April 9, 2016 18:04
Show Gist options
  • Save jmduke/29b298a96cc5de1f6d49380b9d924d25 to your computer and use it in GitHub Desktop.
Save jmduke/29b298a96cc5de1f6d49380b9d924d25 to your computer and use it in GitHub Desktop.

Jakob Egger, who created a number of great apps that I use daily (like Postgres.app and Postico) wrote a post entitled Subscription Pricing is for Stagnating Products:

The one thing I don’t understand is why smaller companies are also trying to switch to subscriptions? Are they also suffering from a stagnating user base, and hoping to increase their bottom line? If that is the case, they are doomed — subscription pricing will only diminish their user base even faster, and won’t fix the underlying problems that led to a lack of growth in the first place.

It’s easy to see where Jakob is coming from: he’s done very well with his paid up-front model for his apps.

However, Jakob’s (much deserved!) success in his pricing model does not translate to definitive proof that paid up-front apps are the way to go.

Instead, subscription models, while not necessarily absolutely better, are a worthwhile strategy in terms of maximizing the amount of value you capture from a customer.

Let’s say there’s an app that costs $50 that I can use to debug and profile database queries. I’m a backend programmer who values his time at $200/hour. As soon as that app saves me fifteen minutes in time, it’s earned its keep. If that app saves me fifteen minutes once a week for a year, it has provided $2,600 in value. If I were to pay $20/month for that app, it would have still delivered ten times more value than I spent on it.

The obvious caveat here is that sometimes, your software’s value proposition doesn’t match that — maybe its something you only use once or twice a year, or something with obvious market substitutes, or something that doesn’t provide obvious value. And in those cases, sure, you shouldn’t use subscription pricing.

Ultimately, you should price your product with the goal of minimizing amount_customer_is_willing_to_pay - amount_customer_spends_on_software — while understanding that amount_customer_is_willing_to_pay maps closely, but not identically, to amount_of_value_generated_by_software. Sometimes, for things like a floor plan generator, the value generated is fairly static — I buy the app, I use it once or twice, and I don’t need to use it again.

But if your app is saving me, say, an hour of a time a week, that’s a tremendous amount of value that isn’t necessarily captured in a $39.99 price tag. And as a consumer, I’m grateful! But I’d still be grateful if I was paying $10/month for the same thing, because I’m getting way more than that out of it.

(Recommended reading: Camels and Rubber Duckies, which might as well be considered the canonical resource on software pricing.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment