
'Cash cow' sales model for a macOS app - walterbell
https://medium.com/@drewmccormack/a-cash-cow-is-on-the-agenda-138a11995595
======
ezekg
> 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](https://keygen.sh), for those that
would rather not spend months building a licensing server in-house. I did this
one too many times. :)

~~~
userbinator
_And that 's why I built [https://keygen.sh](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.

~~~
ezekg
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. ;)

------
antaviana
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.

~~~
oldcynic
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

~~~
chasote
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.

~~~
oldcynic
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".

~~~
chasote
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.

~~~
oldcynic
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.

------
jakobegger
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.

~~~
ropeadopepope
> 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.

~~~
grok2
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.

------
dep_b
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.

~~~
jarfil
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.

------
headcanon
Renoise ([https://www.renoise.com/](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.

------
orasis
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.

------
walterbell
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.

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

~~~
walterbell
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.

------
digi_owl
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.

------
kennydude
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.

------
cprayingmantis
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.

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

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

~~~
JumpCrisscross
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?

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

