3 ms·

I've been spending a lot of time lately thinking about what I'd want for a subscription service. I've paid for subscriptions that allow you to continue to use t

I've been spending a lot of time lately thinking about what I'd want for a subscription service. I've paid for subscriptions that allow you to continue to use the old version indefinitely, as well as subscriptions that completely turning off access to software at the end of the subscription. I think the "use the old version indefinitely" is actually irresponsible as soon as the application opens a network port: it's critical for users to apply security updates as frequently as possible. I don't want any of my users finding the need to run older software: it puts them at risk, and makes customer support more difficult. So, if users can always run the latest-and-greatest regardless of their subscription status, (it seems that) the only way to reward people for having subscriptions is for some subset of functionality to only be available to subscribers. For PhotoStructure's case, I'm not willing to hold their libraries "hostage" in exchange for an active subscription, so even when people allow their subscription to lapse, they still can open and browse and interact with their libraries using the latest-and-greatest version. Paid features are (like auto-updating "smart" folders, auto-organization, geo lookups, and face detection) are applied if a subscription is active. I'm hoping this will be a reasonably fair approach, but I know that it's always a challenge to get people to pay for anything.

RussianCow 6y ago
At that point, you're basically selling a freemium subscription, which is very hard to pull off properly for desktop software, and requires walking a very fine line: if too much of your functionality is paywalled, then the "free" version is useless and the whole exercise is pointless; but if too little of the functionality is paywalled, nobody will pay for your software. IDEs are a great example, because there is little functionality that is important enough to make users want to purchase a subscription, yet doesn't render the software redundant when a user stops paying and it's disabled. But I'd imagine there are also plenty of niches (like yours) for which this type of business model works incredibly well. I hope it works out for you!
pimterry 6y ago
I'm doing the same, with https://httptoolkit.tech/ https://httptoolkit.tech/: the core features are free, but there's advanced extras that require an active subscription. I'm this exact case you cover: it's a powerful developer tool that's very connected to the network & captures the traffic of many of your other apps & devices. It _must_ stay up to date, or users could be at serious risk. Holding back updates from users would be irresponsible. I've noted this in the past, but never really spelled this out fully, and it's important context, thanks! For cases like ours, the upside of freemium over simple paid software though is that the end of the subscription doesn't completely shut down a user's life (unlike totally losing access to your IDE, or your cloud data), and you do need to ensure that. Instead the free user limits are put back into place, but those should generally make workflows inconvenient or less effective, and not catastrophically blocked. In my case, for example, free users lose the ability to import/export collected traffic, but the exported HTTP traffic is in a standardized format anyway (HAR: http://www.softwareishard.com/blog/har-12-spec/ http://www.softwareishard.com/blog/har-12-spec/). Some automated built-in tools go away too, but manual workarounds exist for free, for immediate & short use cases. Those fallbacks & that portability ensure nobody is ever totally locked up by the end of a subscription. It's a very delicate balance (they need to be limited a bit, or nobody buys anything!) but it's been working well for me so far, and as a bootstrapped dev a free basic option is _incredibly_ useful as free marketing. Good luck with PhotoStructure - feel free to get in touch if you want to chat about any of this.

RussianCow 6y ago

At that point, you're basically selling a freemium subscription, which is very hard to pull off properly for desktop software, and requires walking a very fine line: if too much of your functionality is paywalled, then the "free" version is useless and the whole exercise is pointless; but if too little of the functionality is paywalled, nobody will pay for your software. IDEs are a great example, because there is little functionality that is important enough to make users want to purchase a subscription, yet doesn't render the software redundant when a user stops paying and it's disabled. But I'd imagine there are also plenty of niches (like yours) for which this type of business model works incredibly well. I hope it works out for you!

pimterry 6y ago

I'm doing the same, with https://httptoolkit.tech/ https://httptoolkit.tech/: the core features are free, but there's advanced extras that require an active subscription. I'm this exact case you cover: it's a powerful developer tool that's very connected to the network & captures the traffic of many of your other apps & devices. It _must_ stay up to date, or users could be at serious risk. Holding back updates from users would be irresponsible. I've noted this in the past, but never really spelled this out fully, and it's important context, thanks! For cases like ours, the upside of freemium over simple paid software though is that the end of the subscription doesn't completely shut down a user's life (unlike totally losing access to your IDE, or your cloud data), and you do need to ensure that. Instead the free user limits are put back into place, but those should generally make workflows inconvenient or less effective, and not catastrophically blocked. In my case, for example, free users lose the ability to import/export collected traffic, but the exported HTTP traffic is in a standardized format anyway (HAR: http://www.softwareishard.com/blog/har-12-spec/ http://www.softwareishard.com/blog/har-12-spec/). Some automated built-in tools go away too, but manual workarounds exist for free, for immediate & short use cases. Those fallbacks & that portability ensure nobody is ever totally locked up by the end of a subscription. It's a very delicate balance (they need to be limited a bit, or nobody buys anything!) but it's been working well for me so far, and as a bootstrapped dev a free basic option is _incredibly_ useful as free marketing. Good luck with PhotoStructure - feel free to get in touch if you want to chat about any of this.