Subscriptions vs Perpetual Licenses for Desktop Software

Discussions
#1

Just wanted to kick of a discussion on selling subscriptions for desktop software. Sometimes getting your users to purchase an upgrade can be a problem.

I haven’t released my application yet but I have been thinking about this. I was planning on selling subscriptions and perpetual licenses but make the subscription cheaper then the perpetual license to discourage people purchasing a perpetual license. But at the same time didn’t want to lose potential customers who hat subscriptions. What do you think? Has anyone tried selling subscriptions to a desktop application and succeeded?

1 Like
#2

It depends on the type of software and your user base. If you can let us know what the software does and who your ideal customer is, we could give you better advice.

In the recent past, JetBrains and Adobe suffered from some serious user backlash after moving to the subscription model.

On the other side of the spectrum, there are a few desktop softwares that are doing very well with the subscription model - for e.g. Screaming Frog is a popular desktop software in the SEO space that charges yearly. Once the year ends and if you do not renew, then the paid features simply stop working.

If you are starting out, and if your user base is B2B, I would suggest going the subscription route. Nothing is better for your business and motivation than recurring income.

Also, it is a lot easier to go from Recurring subscriptions to One time paid subscriptions than the other way round. If you cannot make up your mind, go with recurring subscriptions - if that business model does not take off, you can always change to one time subscriptions in the future.

#3

Go with subscription OR with perpetual, but not both. Make your life simpler. Make the choice easier for your customer. Make customer support easier. But subscription is preferable if will work for you.

I sell my desktop software product under two brands.

  • my own brand, with a once-off purchase price
  • under another company’s brand (with some enhancements) for a monthly price

There are good reasons why Adobe and JetBrains both moved to subscription pricing. I much prefer selling as a subscription:

  • Monthly Income is more predictable with subscriptions
  • I don’t resent supporting someone with yet another issue two years after they became a customer because they’ll still pay me money
  • I can release updates to all customers, and not have to worry about solving bugs in version 1 AND 2 AND 3, and convincing customers that they should upgrade. If a customer reports a problem, the first thing we do is ensure they are using the most recent update.

But:

  • Is your price high enough to justify subscription pricing? For example, if you’d be charging less than $10/month, a lot of that money will be eaten up in fees and time.
  • Is your market receptive to subscription pricing? If you have strong competitors who charge $100 for a perpetual license, forget about trying to introduce subscription pricing.
3 Likes
#4

I have a relatively small desktop app for local WP dev that I charge a monthly/yearly subscription for – $5/mo, $49/yr. It’s been working out alright (33 active customers atm, a few months in), but sometimes I think it may sell better if I just did a flat $29. I’ve been thinking about experimenting a bit more lately.

#5

At $5/mo, removing $1.5 for fees, takes less than 10 months to overcome one time $29. I doubt you’d do better at $29 unless your customers typically use the application for less than 10 months.

#6

It is possible, but it goes against the grain. When I (personally) buy something for my desktop, this is because I want to unconditionally own it. A notion that what I own will stop working in a month if I do not pay doesn’t fit with my intentions.

For some applications it may work, but I daresay only for those where the application is a desktop one to get access to full power of local machine, but the data are something that is provided by a vendor - the abovementioned SEO tools can fit into that description - vendor provides raw data, and desktop version runs a number of heavy queries against them (which would be prohibitively costly on SaaS). Vendor updates data often, which justifies the recurring payment.

If data are mine and only mine – I do not see why should I pay to the vendor above the initial price.

1 Like
#7

Start with $29/$49 yr (don’t do monthly pricing at that price point) - then increase your pricing by 20% every 3 months until you stop making any sales. Grandfather in existing customers so they always pay the original price they signed up for.

All of us tend to under price our software products. My SaaS webapp started at $10/mo in mid 2013 and is right now at $66/mo. Had I kept my prices constant, my revenue would be 1/6th what it is now.

1 Like
#8

I think exactly the same way.

However, the SEO tool that I mentioned earlier - Screaming Frog - it does not use any server resources or raw data. It is a crawler that lets you crawl your website and generate reports on it. All the data is yours - but when the subscription ends the crawlers no longer work as per the paid plan. What is interesting is that this is completely acceptable in the SEO community, since they are used to using subscription based tools.

It’s very likely that we developers use desktop apps like IDEs and dislike these to be subscription based. Developers are also a tough crowd to sell to.

#9

Subscription is not free money forever, there’s churn. Is your application useful for month/years in the future? Does it depend on some external service or data? Does it have to be updated regularly to maintain functionality, i.e. to be compatible with some regulations, standards, or other software. These are reasons that justify subscription model. It also helps if you’re successful company with a history of regular useful updates, that also makes customers believe that subscription will give them benefits in the future.

And most important question of all - does it have to be a desktop application at all? Web based apps are by default subscription based. I have one application which is not suited for web - has to be fast, to support drag&drop, file operations, etc. However I have another app which could be web based but I made a mistake and didn’t built it that way. I regret that decision now. If it’s built with html/css/js gui, you can always make desktop version using something like Electron if there are benefits for that model, but not the other way around.

1 Like
#10

Assuming your conversion rate stayed the same. Has it? I would be surprised if a x6 price increase hadn’t reduced your conversion rate.

#11

My application is an accounting sort of application. All my competitors in the desktop space only sell perpetual licenses there are saas versions but they are usually not as feature rich. I also don’t think that most people like to have financial data in the cloud. My dilemma is that 3 years from now the software is going to have probably 95% of the features people will ever need so selling a perpetual license means that most customers may never upgrade. My competitors are usually very slow to add features and instead release major versions every 3 - 4 years with a new face lift with some added features.

#12

Any other value you can provide on a recurring basis except for storing data? E.g. law-related updates (tax brackets, …)? Support? People pay subscriptions for repeatedly delivered value.

BTW it is not uncommon to keep financial data in a SaaS anymore. Mint.com and others have changed that long ago.

Well, maybe there is a reason for that. Maybe it is not possible to use recurring payments in your domain.

#13

An idea that I’m toying with is a mix between a subscription and a perpetual licence - giving the benefits to me and my users.

It associates new features with the date they were added. Every license file includes the expiry date (eg: 1 year after purchase) - ie: it’s essentially a 1 year subscription. Once the license file’s expiry date is reached then any new features added after the expiry date will not be available unless they update their license, but the benefit to the user is that they can continue to download new versions of the software - they just won’t have access to new features, but they will get bug fixes to the features that they do have access to.

The benefit to me is that I don’t need to support old versions. It also means that I don’t need to create a new version every year to make money - I just keep adding features when I can.

The benefit to the user is that their license is perpetual (for the features that existed at the license expiry date). If they want the newer features, then they pay for a new license (1 year subscription).

Your thoughts about this approach?

1 Like
#14

@rfctr I think I will have to look at what exactly I can add so I can charge a recurring fee.

@gareth A lot of improvements aren’t exactly new features but improvements on old features. What do you do then? I guess it could work with some software.

#15

Just took a look at Google Analytics. What’s interesting is that the conversion rate seems to have tripled from 2014 to 2016

  1. Jan 2014 - Dec 2014 = average conversion rate = 0.1%
  2. Jan 2016 - Dec 2016 = average conversion rate = 0.3%

I would attribute the increase to the following.
(1) getting better at marketing copy and tactics
(2) the software getting better
(3) better brand recognition in the space

#16

I think this would complicate support as well as development. A self-contained feature is a rare thing indeed.

I’m not arguing against it though; I already do something similar (although not by date). Which is why I think it would complicate things for you.

#17

@akash Being too cheap can hurt your conversion rate as people don’t take you seriously (imagine being offered a $1 bottle of wine and being told that its really good). It might be worth continuing to increase your price (for new users at least) until you start to see the conversion rate go down.

1 Like
#18

Don’t you think you will spend a lot of time explaining it to people? In some areas it is good to innovate and differentiate. But when it comes to licensing/pricing etc I prefer to stick to tried and tested formulas that most people already understand.

2 Likes
#19

Not exactly the same thing, but I moved to subscriptions for HelpSpot (the on-premise version as well as cloud) and it’s gone pretty well overall once I got the pricing dialed in correctly. I also only sell yearly subscriptions, no monthly.

For existing customers we left the owned license/paid support model in place though they can move to subscription if they choose.

#20

So instead of a zoo of N versions you’d have a zoo of 1 version + M license expiration dates?

I feel it may make the code easier to manage.

However, it may lead to a very confusion licensing – you’d have to list every feature available for each license.