'Cash cow' sales model for a macOS app | Hacker News Reader

'Cash cow' sales model for a macOS app

medium.com

63 pointswalterbell38 comments

> In principle, it’s all pretty straightforward. Of course, the devil’s in the details. I was quite surprised how much work was involved in getting it all working. Probably 3–4 months all up.

And that's why I built https://keygen.sh, for those that would rather not spend months building a licensing server in-house. I did this one too many times. :)

And that's why I built https://keygen.sh, for those that would rather not spend months building a licensing server in-house.

For a second, I thought you were the owner of the .us site, reincarnated it under a different domain, and trying to imply that crackers would create a keygen for your software anyway.

But speaking as someone from the other side ;-) any centralised software protection is going to be dead-easy to crack since the checks and ways it makes them are going to be nearly the same between all apps that use it. FlexLM is an existing example of this.

I agree that all software protection is able to be cracked, but I wouldn't say it's "dead-easy" just because it's centralized.

And actually, Keygen is a little bit more unique in that case, because I don't supply any client libraries, and you can also put Keygen behind your own domain (similar to how you would put Stripe behind your own domain). So every piece of software is going to implement things differently.

In addition, you can implement public key signature verification to prevent MITM attacks (each account gets their own 2048-bit RSA pub/priv keys). In the end, the cracker will likely need to spend some time figuring out how your unique piece of software utilizes Keygen, and that will deter the majority.

But like I alluded to, in the end, all software is crackable. There are certainly those who won't stop at the roadblocks. But there's not a lot I can do in that case, especially just being an API. It's more down to implementation. ;)

I think that pure subscription is the only sustainable model. If the incentive for a new customer is the same as keeping an existing customer, you aim for the right product. I find permanent license models are pyramidal and/or foster featuritis.

I disagree. I’d never subscribe to an app whose value isn’t directly tied to the subscription nature. I’d subscribe to Dropbox for example, as it’s an ongoing service, but a text editor? No.

I realise there are some small ongoing costs like support, but customers know when the value doesn’t align with the pricing and they don’t like it.

If you are unable to extract more value than the cost of the subscription, then it is a bad investment, otherwise it is a good investment with more long term chances for you to extract value from it.

If it’s a one-off payment, you have your lifetime worth of chances to extract value. So I’m not following your point here, can you clarify?

Subscriptions have higher chances of survival than permanent licenses because developers have intentionally deferred revenue. So 6 years from now, the motivations to continue operating the business will be higher by a team selling a subscription at $99/year than a permanent license at $299. This way your workflow relying on that tool has higher chances to survive new operating operating systems, new formats and other forms of obsolescence.

I liked Microsoft Money but it is not anymore around. Had it been Money 365, it would still probably be around.

That could be a rational way of looking at it, but consumers aren't rational. I think revenue being tied to value is much more important in purchasing decisions.

Most software that was a one-off purchase model and have now become a subscription model, have added significant service-based features. Examples that come to mind are 1Password that now has family sharing and team collaboration features, or Office 365 which has sync/storage and more web sharing features.

It could be argued that the sustainability of subscriptions enabled these features, but I think it's much more symbiotic - these features enabled a subscription model to work.

For an example of where this hasn't gone as well, I'd look to Ulysses which has moved to a subscription model but doesn't have service based features, and which you do not get to keep using at all if you stop paying. This has resulted in a backlash from customers that can be seen in the reviews online.

I try not to buy subscriptions because you usually lose all functionality at the end. The subscription is usually significantly more expensive than the simple cost of buying a licence for the current version. (eg 1Password). Between those two points there's no benefit for me, the customer, regardless of what marketing tell me.

To add another my thought process is "which sub would I drop to get this?". The answer is usually none. I'm not going to allow myself to end up with dozens of subscriptions for things that don't necessarily require an online component (VPNs and such).

I get it. Subs are great for the company. You'll have a significant number of paying users who never get around to cancelling, or forget what service is tied to the mysterious £4.99 monthly charge, you get to charge double in a year what you used to think was a reasonable cost for outright.

Edit: Clarity

I agree that subscription fatigue is a problem and most will opt out but I feel you are projecting too much malice onto the developers in your last sentence.

Why does asking for the subscription automatically entail they are hoping people will stop using the product but stay subscribed or are charging far more than they think the service is worth?

I think it is too jaded an outlook to see it all as a zero sum fight. The service might just be worth a subscription and the developers want to continue providing it and not be able to with a different business model.

Appropriately-usernamed GP isn't wrong though. SAAS models are loved by entrepreneurs because you get more money at a lower cost: Making a sale is easier because the numbers are lower, but what you rake in is higher because LTV is (usually) higher than what you'd normally charge as a one-off.

The amount of people who forget to unsubscribe, who don't care and leave it running, etc, is shocking. Hell, I'm frugal, and I've been guilty of leaving things like my Prime subscription running for months despite living somewhere I don't even have Amazon. My WoW subscription is still running today even though I haven't logged on the game since 2017. (My monthly costs are sub-300usd... making a $15/mo subscription 5% of my costs)

So yeah, it can absolutely be toxic. I've seen people not be confident enough in their product and rely on tricks rather than worry about making what they charge for attractive enough for users to want to pay for it.

But all in all, unless you're straight up scamming people, I think the incentives behind subscriptions are pro-consumer. Certainly a hell of a lot more than the incentives behind ads.

There are two problems I see as unsolved in the subscription model today:

- Payment gateway fees prevent microsubscriptions. Decentralized digital currencies promised to solve this -- they didn't. When the cost of providing a subscription is $0.001, and you have to charge at least $0.32 to break even, you're forced to tack it on to something bigger. This also massively incentivizes long-term subscription plans (12 month plans), over impulse-buy short term subscriptions.

- Subscription management is done individually by services. This is a feature that your preferred payment provider should be offering. Paypal has a pretty decent implementation of this for users (A shame that Paypal sucks so much for developers). If you could cancel/manage all your subscriptions through your bank, subscription fatigue would be less of a problem I believe.

Not saying it's done with malice aforethought, but it's a known and common pattern. I've done it myself with Amazon Prime and other things where I took a few months longer than I should have to actually go cancel it. Some will let things lie far longer.

If a service is worthless without the online component, Netflix for instance, a sub is clearly the answer and I'll pay gladly. For an editor, utility or IDE having an online account is usually, for me at least, a minor benefit at best when I'll put my files in iCloud, dropbox or git. You made it a tougher sell as you want a rolling commitment. £50 as a one off? I'll spend that on a whim, then probably upgrade in a couple of years.

Most examples I've seen of companies switching to a subscription model end up with a subscription that's more than the previous licence cost. Unless it's something your career or business depends on few would buy every major release widening the real differential further.

That we're having this conversation on a post about a "cash cow sales model" says it all don't you think? It simply starts to look like "we'd like more money from you".

Fair enough, you both make good points. I have been exploring how to make a simple living off one's creations and trying to fight my own cynicism on all the seeming trade offs. Right now that just means staying focused on the creating part and hoping some of you smart folks figure out the best mix of financial feasibility and doing what is right by everyone. These discussions help.

And yes, "cash cow" seems a little uncouth in light of that discussion, haha.

For a small dev I think it's difficult now the big app stores have conditioned so many to believe free, £1.99 and £3.99 are appropriate price points for software. That only works for the tiny few that get a viral lottery win.

I see the attraction of a sub as implicit copy protection. So I wonder why there aren't more ISVs putting the yearly sub markedly lower than the former licence price.

Scrollaway makes great points about microsubscriptions. I think he's right that a central place to easily manage multiple subs would take away most of the pain. Banks seem to specialise in awkward UX and statements that just show "UnknownCo LLC Service" because they're the parent company of coolthing.com's service. Patreon might be better placed to have a try here.

Right now I'm having this battle with myself as the side-project I'm slowly progressing looks like having a sub might be right. I'm still reluctant. Oh the irony. :)

Good luck with your creations.

Oh my god I get a headache just thinking about all the feature flags they'll have to maintain, and all the copywriting to describe each feature, and all the support emails from people asking which features they can use...

What are they going to do when a new feature makes another one obsolete? Keep both? What if they fix a bug in the new version, do they also fix it in the obsolete version?

This sounds like a major maintenance chaos a few years down the line. They'll need to keep adding individual features to incentivise frequent re-purchases, so they'll end up with hundreds of variations of the app, all depending on when you bought it...

Thinking about this makes me so happy about the pay-once model of my apps, I'm so grateful that it works, and that I don't need to squeeze every penny from my customers.

>pay-once model of my apps

it is a pity that people don't like subscriptions because it seems way more sane than fuelling development only with new customers.

For some apps it works to pay once but if it is something that is constantly developed and/or has server costs, this is far from ideal

As long as you make a decent app, there will always be new people that want it.

And the larger your userbase, the more word of mouth advertisement you get. So it might not be the best idea to keep your userbase small by requiring them to pay again and again.

I think you can get by with adding timestamp support to a single feature flag. So the code has IS_PREMIUM everywhere but when you add a new use of it you also manually record the time. Since you know the expiration time of their license you can always determine what features are unlocked based on that.

Then you just develop the app as any other demo-with-upsell app. Users even continue to get bug fixes and other updates after they let the license lapse.

In cases where features are removed, combined, refactored, you'll have to be judicious about what timestamp you apply to the refactor. I would resolve in the customer's favor personally.

Edit: Thinking on this more you might also want a rule like feature flags are only implemented at the view layer. That way your biz logic never gets tripped up on flag checks as features cross paths under the sheets. So its does require a fair amount of code discipline to pull this off

> Oh my god I get a headache just thinking about all the feature flags they'll have to maintain

Why not use a plugin model? Feature flags can be hacked.

Making every feature a plugin is hard -- it requires that the original implementation expose everything possible in APIs to be take advantage of by a plug-in.

That’s a ton of different combinations of flagged features that might or might not exist for a user and almost all possible combinations need to be tested.

If I understand it correctly, when a user pays they get all of the features available at that time. So there could be users with only feature 1, and users with features 1, 2 and 3, but never a user who only had feature 3. That reduces the number of combinations from O(2^n) to at most O(n), and you could keep track of which older features no one has, or offer periodic free/discounted updates to reduce the amount of different versions out there.

Renoise (https://www.renoise.com/) is sold on the same model. Each purchase guarantees free updates for one major version cycle (if you purchase v2.8, you get free updates until v3.8). Might not follow semver rules, but it seems fair to me.

These guys are fooling themselves. If their app provides ongoing value, then subscriptions are the way to go today - it's just a matter of charging the correct price for the perceived value the consumer is receiving.

One question about this model: does the client app need to contact the developer’s licensing server on every app start, or after every app upgrade, or only at the time of in-app purchase?

If there’s only a one-time “phone home” to the license server, this seems like a good revenue model that balances the needs of users and iOS developers.

In-app purchases are handled directly by Apple, so you can do away with a licensing server and just enforce licensing on the client.

But they are allowing all clients to get new binaries (with bug fixes and new features) while limiting them to features within a rolling 12 month window from time of purchase. Apple doesn’t have the ability to gate features that way.

Software, like books, only has a market as long as the distribution is a pain in the behind. Once the distribution is as easy as the press of a (virtual) button, the market basically evaporates.

SetApp is a great way to do subscriptions on macOS. It has lots of apps, and lets me try them whenever I want without really comprimising on much.

I had to read this very carefully to determine if it was parody or not. This seems just like the old system of selling software. Get a free demo, sell the actual software, 12 months later add more features rinse and repeat. There will always be hold outs content with their feature set but there will always be people on the leading edge and it all balances out but this doesn't seem like anything particularly new or novel.

Yea this is the way a lot of enterprise software has been sold for decades... especially useful if there's a cost to the software company for delivering upgrades (e.g. shipping CDs and installing it), you only have to support for 12 months and after that you're off the hook, if the client doesn't pay up.

In this model the user continues to get bug fixes (and likely new OS support) even after their licence expires.

Bug fixes make sense, but I wonder if it is reasonable to expect/provide perpetual OS support based on a single purchase?

How does one differentiate fixes and feature? For example, suppose a new TLS standard is adopted. This requires work to implement. Is the change a fix or an upgrade? Will the team be indefinitely required to issue updates to the old TLS?

I like the agenda-pricing concept. But it feels like a poor-man’s compromise for a subscription. Why not permit downloads of an executable any time a sub is valid?

Easy: what's the feature you're selling? Is it "TLS 1.0" or "secure connections"?

The key difference is that it is NOT a twelve month cycle of adding features. The features are added throughout the year, and you get one year's worth of new features from whenever you buy it.

This helps with two things; one, you don't have to have all the new features released at once. You can release them as you go, and people (who paid) will get them as you release them.

Second, it stops the timing issues that you have with the traditional once-a-year upgrade. If you are a consumer, you don't want to buy the previous version if the new version is coming out soon. And as a seller, it means all of your sales are packed into right after you release the new version.

This seems like a good way to smooth out that cycle, for both buyers and sellers.

Yeah, maybe I'm old, but this just seems like how enterprise software is sold. We've been doing it this way forever.

Reply on news.ycombinator.com