My problem with the 1Password subscription model(medium.com)
medium.com
My problem with the 1Password subscription model
https://medium.com/@guisebule/to-catch-a-liar-1password-edition-4bfa30fbd7e4
26 comments
It's definitely worrying to me that everyone is going to SaaS on everything since it removes the basic purpose of having a PC or even a smart phone: to do the computing as close to myself as possible. Some things fit SaaS as a natural consequence of their implementation but password managers and image editors aren't good fits for that and they're clearly a cash grab. Eventually, I plan to ditch 1Password when I have the time to find a roughly analogous application (which I've seen a couple but not good enough IMO) since they can't provide local storage for my existing vaults.
I'm still using 1Password on my Macbook, but since I've gone full time Linux at home, I had to migrate off. Keepass + SyncThing is more than enough to keep everything synced for me.
Exactly same here.
Macpass for osx with browser plugin works awesome for me.
Macpass for osx with browser plugin works awesome for me.
I think that those that think the upgrade model will suffice are missing a few things: The increase in free/customer-as-the-product solutions that undercut existing software and by extension, the race to the bottom when it comes to app prices.
Back in the 90's, you bought a thick box with a thick manual and physical media for $25 dollars. You didn't have to worry about some App Store selling just as good software for $0.99
Back in the 90's, you bought a thick box with a thick manual and physical media for $25 dollars. You didn't have to worry about some App Store selling just as good software for $0.99
They can say they support both until they're blue in the face. Version 6 for Windows doesn't support local passwords and they keep kicking the can further and further down the road with no actual roadmap for it. The bullshit that it's a difficult feature to implement is infuriating. There's absolutely no way it's a massive effort to enable writing new passwords on a local safe when you can open and read existing safe's just fine, and create new passwords in a local cache if I'm tied to a "cloud database".
You want to push everyone to subscription and you know it. Don't be "that guy" - right now they're 100% "that guy".
You want to push everyone to subscription and you know it. Don't be "that guy" - right now they're 100% "that guy".
Seems like they're going to keep things as they are, if that's what you'd like.
https://twitter.com/1Password/status/884791799138615296
https://twitter.com/1Password/status/884791799138615296
For now but who knows what will happen next year? Once they make enough money with subscription they will stop caring.
So Windows users have to use the crappy EOL v4 client?
That's what I'm using now. What's crappy about it? Works great for me.
it's abandoned feature-wise and ui-wise it's inconsistent with the rest of the product offerings while they are clearly putting their time in the v6 with its cloud focus.
Software companies absolutely need recurring revenues to survive, new users are hard and expensive to get, and you need to keep an active development team. Historically it was upgrades, you gave customers new features in trade for upgrade revenue, which was usually a great deal for all.
But nowadays that's lots harder, upgrades don't exist on iOS at all. And when their key features are already in the product, lots of users won't see the point of upgrading.
But what they and the author miss is that keeping software operating is a great deal of work. In 1Password's case just compatibility and bug fixing on 4 or 5 operating systems is likely a substantial ongoing effort. On iOS alone my guess is they have to support 3 different major OS versions at a time.
The disconnect is users who bought a version that worked on iOS 7 or Windows 7 and never paid a dime since expecting a free Windows 10 and iOS 11 update.
But nowadays that's lots harder, upgrades don't exist on iOS at all. And when their key features are already in the product, lots of users won't see the point of upgrading.
But what they and the author miss is that keeping software operating is a great deal of work. In 1Password's case just compatibility and bug fixing on 4 or 5 operating systems is likely a substantial ongoing effort. On iOS alone my guess is they have to support 3 different major OS versions at a time.
The disconnect is users who bought a version that worked on iOS 7 or Windows 7 and never paid a dime since expecting a free Windows 10 and iOS 11 update.
Then charge for the upgrade by doing the standard major version bump (Foo2, just like Foo but now with more Bar!) and don't try to bullshit us. Companies don't need recurring revenue to survive, they need to sell product to survive. If their biz model consists of trying to bleed their current customer base one drop at a time I will look elsewhere.
-current 1password user and evangelist who will drop it in a heartbeat if forced into a subscription
-current 1password user and evangelist who will drop it in a heartbeat if forced into a subscription
This is the correct answer. Every time I hear that a software vendor needs recurring revenue to survive, I think back to the entire history of the software industry where this was clearly not the case until every recently. Its gotten to the point now where anyone who makes some sort of software believes that are a service that must be paid for by subscription.
Don't be those guys, have a good long hard think about why you deserve that recurring revenue and if its not immediately obvious, chances are you are just chasing the dollar rather than trying to solve a problem.
Don't be those guys, have a good long hard think about why you deserve that recurring revenue and if its not immediately obvious, chances are you are just chasing the dollar rather than trying to solve a problem.
You don't know much about the history of software sales. I've worked at software companies for 30 years and you are wrong. The first company i worked for folded down from 12 employees to 3 because revenues couldn't support us. We got our first upgrade out ($29 for existing customers on $99 retail) and it saved the company. Two years later we had 4 products and 30 employees.
If we had been forced to give the upgrade away for free to existing customers like iOS requires, we would have shut down.
If we had been forced to give the upgrade away for free to existing customers like iOS requires, we would have shut down.
iOS doesn't allow you to charge existing users for a version bump.
It is an entitrely new package that shares part of the name. I could provide numerous examples, but you already know about them. You keep minor version bumps for fixes and patches while major changes you plan to charge for are a part of the new package.
The whole point of paid upgrades is
1) that you charge existing users signicantly less than new users, and
2) that you get to contact existing users directly to tell them about it.
Creating an entirely new "package" on iOS is an entirely new app. Which means unless you use App Groups, that your users will lose all the data they've created in your app, which for some categories of apps is a terrible user experience. And implementing App Groups to transfer old data is a bunch of extra work that you should have gotten for free by using Coredata.
Worse, your existing users won't be told about it by the App Store. The App Store won't provide email or physical addresses to let you inform them about it. So to reach them, you have to do something like
1) Update existing app with a notice and a link to the new app on the store for the user to buy it. This doesn't work for apps that users typically don't use often, for example my most successful app is a "fire and forget" type app the once a user sets up, they rarely ever need to open it again.
2) Get existing users to give you email addresses. Forcing them to do so is against App Store rules, so you need a strategy to induce a high percentage to do so during install/signup, that's hard. It also requires prescience. If you don't start this in an early release of your app you'll miss out on most of your installed base.
3) Use push notifications. That's hard too. You have to convince users to authorize your app to allow push notifications. Again have to do this from early versions, or again lose most of your installed base. Many users won't authorize notifications for your app.
That's just the problem of being able to reach your installed base. Actually giving them a discounted price is another hurdle that's difficult. There is no App Store option to have two different purchase prices for different user groups for a new app. So you have to do it by hand
1) Generate a custom code in the existing app, and link to the new app and tell your existing user to use the code when they launch the app to purchase it at the upgrade price instead of the retail price. This means your new app can't be a paid app! It can only be free with in-app purchase, so an in-app purchase business model has to work for your app. And it's extra work, you need reasonably secure code generation, and good UI so users understand it, or to use App Groups to automate it.
Also, you probably need to determine whether a user of the existing app qualifies for a discounted upgrade price. For example, let's say your old app is $10, the new app is $20, and you want to offer existing users a $5 upgrade price as a thank you. You need to make sure new users don't just download the old app and upgrade instead of buying the new app directly. Or you keep the price at $10, but make the old version free as a trial product for people to use before upgrading. You want existing users to pay $5 to upgrade, and new users to pay $10. So how do you tell new from old?
If they never deleted the app since install, you can use installation date. But if they deleted the app, then read about the 2.0 release and it's new features and re-installed, their install date is now post 2.0 release. Unless your app has email registration and the deleted/reinstalled user actually used it, there is no way to determine if they are existing users or not. Apple doesn't allow developers to fingerprint devices (the last loophole was Keychain, which they recently closed).
2) One way to do via your existing app is to make new features an in-app purchase. That means you don't lose existing data, and you can reach all existing users. But it also makes the purchase process for new users shitty. They buy the app on the store, then they realize it doesn't have the shiny new 2.0 features, it's really the old 1.0 features and they have to pay again to get the latest, best features. That's hard to explain in the limited space the App Store gives you, and is just a fantastic inducement to get a ton of terrible 1 star reviews.
You can make the 2.0 version free on the store with the 1.0 features already activated for free, and the 2.0 features an in-app purchase, this is straightforward for new users. Again in this case you need to automatically determine if the user purchased before 2.0 was released or after, and charge different prices based on that, and you'll have a ton of edge cases where existing users look like new users because of install dates. You'll get a ton of 1 star reviews from that. And it's not even a reasonable path if your 1.0 features still have too much value to give away for free.
So creating a paid upgrade path is difficult on iOS, it's hard to reach existing users to market your upgrade, and all of the ways to emulate paid upgrades have significant shortcomings. I don't know of any examples that work well, if you do, please share them. I'll thank you, and admit that I'm wrong.
Creating an entirely new "package" on iOS is an entirely new app. Which means unless you use App Groups, that your users will lose all the data they've created in your app, which for some categories of apps is a terrible user experience. And implementing App Groups to transfer old data is a bunch of extra work that you should have gotten for free by using Coredata.
Worse, your existing users won't be told about it by the App Store. The App Store won't provide email or physical addresses to let you inform them about it. So to reach them, you have to do something like
1) Update existing app with a notice and a link to the new app on the store for the user to buy it. This doesn't work for apps that users typically don't use often, for example my most successful app is a "fire and forget" type app the once a user sets up, they rarely ever need to open it again.
2) Get existing users to give you email addresses. Forcing them to do so is against App Store rules, so you need a strategy to induce a high percentage to do so during install/signup, that's hard. It also requires prescience. If you don't start this in an early release of your app you'll miss out on most of your installed base.
3) Use push notifications. That's hard too. You have to convince users to authorize your app to allow push notifications. Again have to do this from early versions, or again lose most of your installed base. Many users won't authorize notifications for your app.
That's just the problem of being able to reach your installed base. Actually giving them a discounted price is another hurdle that's difficult. There is no App Store option to have two different purchase prices for different user groups for a new app. So you have to do it by hand
1) Generate a custom code in the existing app, and link to the new app and tell your existing user to use the code when they launch the app to purchase it at the upgrade price instead of the retail price. This means your new app can't be a paid app! It can only be free with in-app purchase, so an in-app purchase business model has to work for your app. And it's extra work, you need reasonably secure code generation, and good UI so users understand it, or to use App Groups to automate it.
Also, you probably need to determine whether a user of the existing app qualifies for a discounted upgrade price. For example, let's say your old app is $10, the new app is $20, and you want to offer existing users a $5 upgrade price as a thank you. You need to make sure new users don't just download the old app and upgrade instead of buying the new app directly. Or you keep the price at $10, but make the old version free as a trial product for people to use before upgrading. You want existing users to pay $5 to upgrade, and new users to pay $10. So how do you tell new from old?
If they never deleted the app since install, you can use installation date. But if they deleted the app, then read about the 2.0 release and it's new features and re-installed, their install date is now post 2.0 release. Unless your app has email registration and the deleted/reinstalled user actually used it, there is no way to determine if they are existing users or not. Apple doesn't allow developers to fingerprint devices (the last loophole was Keychain, which they recently closed).
2) One way to do via your existing app is to make new features an in-app purchase. That means you don't lose existing data, and you can reach all existing users. But it also makes the purchase process for new users shitty. They buy the app on the store, then they realize it doesn't have the shiny new 2.0 features, it's really the old 1.0 features and they have to pay again to get the latest, best features. That's hard to explain in the limited space the App Store gives you, and is just a fantastic inducement to get a ton of terrible 1 star reviews.
You can make the 2.0 version free on the store with the 1.0 features already activated for free, and the 2.0 features an in-app purchase, this is straightforward for new users. Again in this case you need to automatically determine if the user purchased before 2.0 was released or after, and charge different prices based on that, and you'll have a ton of edge cases where existing users look like new users because of install dates. You'll get a ton of 1 star reviews from that. And it's not even a reasonable path if your 1.0 features still have too much value to give away for free.
So creating a paid upgrade path is difficult on iOS, it's hard to reach existing users to market your upgrade, and all of the ways to emulate paid upgrades have significant shortcomings. I don't know of any examples that work well, if you do, please share them. I'll thank you, and admit that I'm wrong.
Companies managed to survive a few last decades without having subscriptions and suddenly they need it to survive? Upgrades exist on iOS, you just release a new app. It is not different from times before App Store.
Stop tolerating this subscription model or you will regret it one day once everyone switches to it and you will be paying 200 bucks each month to use your software and if you stop you will have nothing.
Stop tolerating this subscription model or you will regret it one day once everyone switches to it and you will be paying 200 bucks each month to use your software and if you stop you will have nothing.
An upgrade means you can charge 30-40% of the retail price of the new version to existing users. That doesn't exist on iOS, Apple doesn't even let developers know who your customers are.
There is a way around it. When you release a new version you offer it for cheaper for limited time and you notify your existing customers. Of course, some new customers will buy it as well when it is discounted but it is acceptable loss.
Sorry, just think about it, that's a terrible solution.
First, remember that the Apple App Store doesn't give you any way to directly notify existing customers. See my other post, it's a great deal of work to induce customers to give you email addresses/etc.
But lets say you have emails for most of your users, or that you autoupdate your app to notify them that the new version is out and for a limited time available for a cheap price. Most of your users are going to miss this email, or forget about the discount, or not use the app during the discount period and never see the notice.
Those who miss the discount window are going to be pissed. That's going to be a lot of 1 star reviews. Some are going to be pissed they, as long standing users, didn't get a "real discount" since you gave it to anyone who bought it at the same time. That's more 1 star reviews.
But the worst problem is you are discounting the value of your product to new users. Your retail price should be set where it maximizes long term revenues (if you thought you would make more money by discounting you'd already be doing that).
For existing users who have already paid you for much of the value, you want to set your upgrade price at a reasonable value for the additional features of the new version. That price normally should be lots lower than retail, essentially 20-30% in any mature product.
By giving the new users a price that is the 20-30% of what they would normally pay, you are leaving a ton of money on the table. Worse, you are front-loading sales. Anyone who planned to pay full retail in the future will rush to take advantage of the discount. How do you think sales for the rest of the year will look?
Imagine you expected to sell 36,000 copies to new users this year at $10 each, or a net of $252,000 this year after Apple's 30% fee.
You announce the new version is only $3 on the store for a month, but only tell the 50,000 existing users that you have email addresses for. You get a great response from them, and sell 20,000 units to existing customers the first month, netting $40k.
But instead of selling your typical 3,000 units to new users the month, you instead sell 12,000 units to new users. What happened? Well, anyone who was likely to purchase this year and found out about the huge temporary discount, bought now. And lots found out, either by checking the store, or hearing from existing users (50k people have lots of friends), or from bloggers, or one of the hundreds of discount alert services, etc, etc.
And by front loading their purchases, your sales will be lower over the remainder of the year, by the 9,000 extra new users who took advantage of the discount. So instead of netting $292k this year, you are going to net less. How much less? Your 36k in new users now net you only $168k, for a total of $208k, costing you $84k or 25% of revenues.
The problem with discounting for everyone is that the shorter the discount period, the angrier your existing users will be. And the longer the discount period the more money it will cost you. It's a no win approach. You absolutely need a way to qualify existing users to provide the upgrade price, or it can't work. You'd be better off never discounting and forcing existing users to pay full price to re-buy a slightly better version of the app they already own.
First, remember that the Apple App Store doesn't give you any way to directly notify existing customers. See my other post, it's a great deal of work to induce customers to give you email addresses/etc.
But lets say you have emails for most of your users, or that you autoupdate your app to notify them that the new version is out and for a limited time available for a cheap price. Most of your users are going to miss this email, or forget about the discount, or not use the app during the discount period and never see the notice.
Those who miss the discount window are going to be pissed. That's going to be a lot of 1 star reviews. Some are going to be pissed they, as long standing users, didn't get a "real discount" since you gave it to anyone who bought it at the same time. That's more 1 star reviews.
But the worst problem is you are discounting the value of your product to new users. Your retail price should be set where it maximizes long term revenues (if you thought you would make more money by discounting you'd already be doing that).
For existing users who have already paid you for much of the value, you want to set your upgrade price at a reasonable value for the additional features of the new version. That price normally should be lots lower than retail, essentially 20-30% in any mature product.
By giving the new users a price that is the 20-30% of what they would normally pay, you are leaving a ton of money on the table. Worse, you are front-loading sales. Anyone who planned to pay full retail in the future will rush to take advantage of the discount. How do you think sales for the rest of the year will look?
Imagine you expected to sell 36,000 copies to new users this year at $10 each, or a net of $252,000 this year after Apple's 30% fee.
You announce the new version is only $3 on the store for a month, but only tell the 50,000 existing users that you have email addresses for. You get a great response from them, and sell 20,000 units to existing customers the first month, netting $40k.
But instead of selling your typical 3,000 units to new users the month, you instead sell 12,000 units to new users. What happened? Well, anyone who was likely to purchase this year and found out about the huge temporary discount, bought now. And lots found out, either by checking the store, or hearing from existing users (50k people have lots of friends), or from bloggers, or one of the hundreds of discount alert services, etc, etc.
And by front loading their purchases, your sales will be lower over the remainder of the year, by the 9,000 extra new users who took advantage of the discount. So instead of netting $292k this year, you are going to net less. How much less? Your 36k in new users now net you only $168k, for a total of $208k, costing you $84k or 25% of revenues.
The problem with discounting for everyone is that the shorter the discount period, the angrier your existing users will be. And the longer the discount period the more money it will cost you. It's a no win approach. You absolutely need a way to qualify existing users to provide the upgrade price, or it can't work. You'd be better off never discounting and forcing existing users to pay full price to re-buy a slightly better version of the app they already own.
Well, you might think it is a terrible solution but it is widely used. Recent examples that come to my mind: Things 3 and Affinity Photo (was not upgrade but it was still discounted on launch).
I had the exact opposite reaction. I have been long hoping that they would move to a recurring revenue model.
I WANT my password manager to be backed by a financially stable, healthy company who invests in updates and maintenance. This is an area I am happy to pay a premium for and I am thrilled that 1Password is moving this direction.
I WANT my password manager to be backed by a financially stable, healthy company who invests in updates and maintenance. This is an area I am happy to pay a premium for and I am thrilled that 1Password is moving this direction.
Having a recurring revenue model does not mean you have a stable company. You might love it but many others don't and if they don't have enough customers on subscription it will be worse for you because you depend on their servers to operate and if they shut down your software stops working.
[deleted]
Why can't one of those big cloud/disk providers (Dropbox or Amazon or Microsoft or Google or Apple) come up with such a Password Manager? In fact, they can integrate it really well too.