
Show HN: Keygen – A dead-simple software licensing API built for developers - ezekg
https://keygen.sh
======
rrosen326
Since I know you are figuring this all out, here’s some pricing feedback for
you:

I’m a weekender - building a desktop app (OS X & Win) for individuals and
small businesses. I hope it turns into a real business some day, but as
experience would show, it probably won’t.

On the low end, $24/month is way too much for me. I would find it offensive to
pay $24/month for a licensing solution, when I pay $0 for python, flask,
electron, NPM, Vue, and the myriad other technologies I rely on heavily.
(Note, I don’t _think_ it is offensive - but I _feel_ it.)

My gut feel on pricing - don’t try to squeeze money from a stone. Give away
the low end. You won’t make much money there anyway and you will almost
certainly turn off many potential users and proponents. Get them hooked. Let
them promote for you. Don’t let them find an alternative. Then, when they
start making money, you start making money.

If I have a viable business going I will have a totally different feel on how
I would see this expenditure.

2 cents for you.

~~~
ezekg
Appreciate the feedback. (Seriously, helps a lot!) What would be a price point
that works for you? I definitely think there's room for a smaller plan, so I'd
love to hear your thoughts. I've done smaller custom plans in the past for
makers who are just getting started with an app (or in the process of building
one) with a low active user limit. But in the end, $288/yr is not _that much_
for something that helps you make money--especially considering that you'll
likely have to _spend_ money to _make_ money as an app developer. And lastly,
I don't think comparing a _product_ to open source is the right thing to do--
especially considering that you have to host Flask, distribute Electron, etc.,
all which cost money.

~~~
jfindley
Appreciate that hosting isn't free, but having some sort of $0 plan would
greatly drive adoption, at fairly little cost. I personally would be unlikely
to launch a product that cost me a monthly fee just to run, even with zero
paying users. Once I have paying users, I become a lot more willing to pay
you. You could consider something like the following plan: Testing. $0/mo, 50
users, no support.

It'll be more effective marketing than anything else you could reasonably buy,
and unless you have serious architectural/scaling issues shouldn't be too
expensive for you.

~~~
gol706
I agree. I think that the pricing is fair for when you have paying customers
on the system (at least for my business model), but the 7 day trial isn't
really enough time to do a proof of concept to see if Keygen would work for
me. I know most companies will extend your free trial if you ask nicely, but
ugh. I should have a free option available until I get to Prod.

~~~
ezekg
If you want an extended trial, I'm all for hooking you up with one that lasts
until you launch (or whatever is needed for you). Though not something I want
to do by default at the moment, simply due to the fact that free users usually
require more support than paid users.

------
r1ch
The hard part with software licensing is making it resistant to cracking. This
doesn't attempt to make things difficult, it would take under an hour to crack
any app that uses this for licensing.

I suppose the target for this service are app developers who don't have their
own website / server infrastructure. It seems trivial to issue your own
license tokens and have clients check in with your website for an OK / BAD
response.

~~~
user5994461
>>> The hard part with software licensing is making it resistant to cracking.

You couldn't be further from the truth.

No one is gonna crack your software. There isn't 1% of your customers who
could disassemble your software. There isn't 0.1% who could make a crack.
Enterprise users don't even run cracked software.

Software licensing is about making as little work as possible to block non
paying users. Time spent developing useless counter measures is time not spent
selling and developing your product.

A good old key file with only the last payment date will do just fine. Send
everyone who didn't pay since last year to your payment page :D

~~~
worstscenario
Someone would just NOP out the check and publish a cracked version on the
internet, so everyone who can't crack it will be able to download the cracked
version.

~~~
gh02t
I think the point is that the only way to make your software genuinely
resistant to cracking is an onerous DRM scheme like you see with games or
obscure engineering software. Stuff that takes a lot of work to implement (or
$$ to license) and more importantly actively annoys _legitimate_ users.

Anything short of that is probably going to be cracked for software that is
even modestly popular. I think setting the bar just high enough to keep
grandma from breaking it is pretty much just as good as something more
sophisticated.

The psychology of it is, you can't stop nefarious users ultimately. But you
need something that at least makes honest users take some extra action
specifically to crack your software. Making them feel like they are pirating
something will stop most honest users.

~~~
_e
I think it comes down to what is easier, faster and most convenient to do --
download a cracked copy from a bittorrent site or jump through the hurdles of
ordering a legitimate copy.

There have been many companies/independent developers who have used the "warez
scene" to intentionally "leak" and distribute their software. As the software
gains traction they make it easy for the user to buy a license so they can
update the software from within the software. Otherwise the user has to wait
until a new cracked copy gets released.

You'll never ever stop anyone from cracking your software but convenience does
come at a price.

~~~
pluma
Except the legitimate distribution channel doesn't have to be _easier_ than
the illegitimate one, it just has to be _easy enough_. There are plenty of
incentives to use the legitimate channel, all you have to do is not make it
too annoying.

------
KenanSulayman
Not to sound too negative, but NOPing out the invocation bypasses the
licensing. At least in the native version. I like approaches where parts of
the app are downloaded after licensing went through and the license key is
actually a public key.

But maybe I’m missing the point?

~~~
X-Istence
NOP'ing out the invocation has always been an issue. There are a variety of
frameworks for the Mac that make license keys using public/private key pairs,
and a simple change to the ASM to return early and report success is easy
enough to do.

There is:

[https://github.com/glebd/cocoafob](https://github.com/glebd/cocoafob)

For example, there is one other one that I can't remember the name for off the
top of my head.

~~~
gruez
The respectable frameworks I've seen also offer obsfucation/virtualization to
deter tampering. Thats the harder and more critical part.

------
ianamartin
I'm not sure how this holds up to the promise of "Sell outside the app store
and pocket that extra 30%."

If you're selling iOS apps, you have no choice but the app store. You could
try giving the app away for free on the iOS App Store and shunting people to a
website to purchase the license after a certain amount of time, but I'm
certain that breaks Apple's rules. Same goes for the Mac App Store.

You'd get shut down pretty quickly if you ever managed to squeak through the
approval process.

Based on the code examples provided on the website, I don't see any of the
most popular languages use for apps that go in an "app store" of any kind
(Obj-C, Swift, Java)

I'm sure intent is not to be misleading, but I don't see how this can recoup a
30% app store take. Could you explain that in more detail, since you are
replying in this thread?

~~~
asteadman
To be fair, this is exactly how I use Netflix. I have a free app that I pay to
use completely outside the app store. Not sure of the actual rules, but it's
definitely possible.

~~~
firloop
It's fine to have out of band payments for subscription services on the App
Store, so long as it's possible to subscribe to the service through an in app
purchase and you don't advertise paying outside the app within the app.

Apple takes these matters pretty seriously, it is their bottom line after all.
I once had an app get rejected by App Review because it was possible to buy a
subscription from the WebView that opened the Forgot Password page.

~~~
ianamartin
It's not Apple's bottom line. Not in any way.

But they will shut down any out-of-band payment options. There is nothing even
remotely fine about this.

~~~
ezekg
Correct. In my experience in talking with Apple/Google, that is most
definitely _not_ a good idea and could get your developer license revoked.
Maybe someday they'll open up the walled garden (lmao ok), but for now devs
should stick to only selling desktop apps independently.

------
top_post
I had this exact same idea but never executed on it. I like everything about
this, implementation to web design. I hope you slay with this.

------
theprop
Way too expensive in respect to users...at $.20/user/year...for 100k users,
it's $20k/year. This vs. most installers that actually pay you...

~~~
ezekg
I don't currently offer usage-based plans, so not sure where that came from. I
offer $24, $49 and $99/mo plans with custom plans offered to companies who
have more than 5,000 active users (which is _a lot_ if you've ever launched a
product before). Either way, at the lowest plan you're spending $288/yr, which
is _far_ less than the average cost it would take to build a homegrown
licensing solution, assuming you don't value your time at $0 (which developers
tend to do when opting to build things themselves--Mike Perham of Sidekiq has
a good tidbit on this[0]).

[0]: [https://github.com/mperham/sidekiq/wiki/Build-vs-
Buy](https://github.com/mperham/sidekiq/wiki/Build-vs-Buy)

------
timvdalen
Previous discussion:
[https://news.ycombinator.com/item?id=12870031](https://news.ycombinator.com/item?id=12870031)

~~~
ezekg
Founder here--I definitely recommend reading through that thread if you have
time. That was back whenever this was simply an idea in my head (scratching my
own itch) and I created a landing page for it to gauge interest. I admit that
I didn't handle myself/answer questions as well as I could have in that thread
(confusing cracking w/ key generation was embarrassing--and I do know the
difference--but nerves got the best of me a few times in that thread so I
didn't read things as well as I should have). I honestly didn't expect to hit
the front page so was a little thrown off/overly excited because of it. ;P

Anyways, I launched Keygen last month after a 3-month beta and am stoked to
get some more feedback from HN now that the product is _real_. I put a
considerable amount of work into the documentation (and the design), so be
sure to look around!

~~~
timvdalen
I will definitely check it out - I had Keygen bookmarked from that thread back
then so I could play with it once it launched.

------
dsr_
My company used to use a library which had an enforced license. It was a major
headache -- and it was the simplest possible kind of license, where they sent
us an encrypted key file and we placed it on each server.

As soon as we could, we negotiated an end to that. Instead, they ask us each
year how many licenses we need and send us a bill. They have an audit right,
but they've never used it. It won't be a problem if they do, because we are
fully compliant.

------
fermion_now
This doesn't look like a product I'd use myself (web dev) - but I'm sure a lot
of native developers will find it useful.

I really like the landing page - particularly the section with examples in
different programming languages. I'd maybe suggest a little more copy on
uptime-related matters. I see you have a status page, maybe link to this a
little more prominently?

Good luck!

------
sjg007
I would charge per successful activation.

~~~
ezekg
I was on the fence about this for awhile. So what about the customers who use
Keygen for feature-licensing? They would pay more while the customer who uses
Keygen to license their entire product pays _way_ less--not exactly fair. For
the time being, I think the flat-monthly-fee works. Though, I'm all for
discussing a custom plan if that doesn't work for you, as mentioned on the
pricing page. :)

~~~
sjg007
No reason not to offer both models. Pay per use is generally higher than a
subscription which explains the benefit of the subscription to the customer.
As the provider you sacrifice some overall peak for guaranteed revenue.

------
beefhash
The developer(s) of this may really want to rethink the name.

Not only is it pretty un-googleable due to other, older results likely taking
priority, it's also likely that a potential customer accidentally lands on a
website full of malvertising. That aside, the word "keygen" is probably
morally negative to many people.

The technology looks fascinating, however.

~~~
ezekg
Founder here--appreciate the feedback! The name is both tongue-and-cheek as
well as an attempt to redeem the word. Years from now, you might search
”keygen for X” and be shown pages of results related to this product instead
of pirated software. And since the product is primarily geared towards
developers, I think it works (and also invokes a little curiosity). Also, I
haven't seen any SEO issues thus far, especially since I'm not really trying
to rank for searches that contain ‘keygen’ right now.

~~~
TylerE
> Years from now, you might search ”keygen for X” and be shown pages of
> results related to this product instead of pirated software.

Care to bet money on that? That's rather shocking hubris.

~~~
_e
Actually, this gave me an idea. The founder of keygen.sh can generate landing
pages advertising cracks/serials/keygens for download on tons and tons of
different software.

When the search engines index these landing pages, whoever has an alert setup
to monitor their products will get a notification about your website. Let
google automate your marketing.

The other benefit is that you can use your logs as a sales tool when pitching
your product to developers. "Hey Developer, 38 people came to <<url>> today
looking for a crack/serial to your <<software name>>." Hopefully those
developers will then visit your page for more information which turns into a
sale.

~~~
rl3
This is brilliant in principle.

However, does it run afoul of acceptable SEO practices? Namely those covering
autogenerated content.

~~~
_e
Thank you. It would come down to execution.

One way to solve that is to track "scene releases" [0] and download the
releases for software you think could become keygen.sh customers. Then reverse
engineer the cracks or patches and document the process. Next, show how
keygen.sh would have prevented this cracking technique. Now you have original
content that will help you sell keygen.sh.

A byproduct of this will continuously give you ideas on how to improve
keygen.sh.

It is very important to note that keygen.sh or any licensing platform will
ever be uncrackable but if you can delay the time software gets cracked by a
week or two then it could possibly translate into more sales for the keygen.sh
customer.

At the end of the day, it is on the keygen.sh customer to sell their product
and keygen.sh to delay the release of a crack for it.

[0] [https://torrentfreak.com/27-years-of-warez-scene-release-
inf...](https://torrentfreak.com/27-years-of-warez-scene-release-info-leaked-
in-giant-database/)

~~~
rl3
> _Then reverse engineer the cracks or patches and document the process._

Sounds prohibitively work intensive in the extreme.

~~~
_e
There could be ways to automate the process [0] with machine learning [1].

[0] [https://www.cuckoosandbox.org/](https://www.cuckoosandbox.org/)

[1] [http://www.covert.io/research-
papers/security/Automatic%20An...](http://www.covert.io/research-
papers/security/Automatic%20Analysis%20of%20Malware%20Behavior%20using%20Machine%20Learning.pdf)

------
dgudkov
Offline mode still not available?

~~~
ezekg
Since my initial product is an API, it's going to have limited support simply
due to the nature of the product. You can set up licenses to require periodic
check-ins (e.g. phone check-ins or something similar via an online form may
work), but other than that, Keygen needs a periodic internet connection. How
would you envision Keygen working offline?

~~~
asmosoinio
Not OP, but something like like:

1\. Receive code in an email 2\. Enter code in app X to license 3\. Use app X

So maybe a scenario you purposely are not supporting

~~~
ezekg
Definitely a popular choice. There are open source libararies for
public/private key license validation (CocoaFob is a popular one for macOS),
and I don't really think this aligns with the current product i.e. the API.
Maybe in the future I can expand if there's demand for it, but I'm not sure
what I could offer that the open source community can't already offer. :)

~~~
jetti
> I'm not sure what I could offer that the open source community can't already
> offer.

Support! Offering support when things go wrong is huge.

------
JCharante
I'm not an English major, but in the FAQ section under "Does Keygen prevent
cracking?" you wrote "requring" instead of "requiring".

~~~
ezekg
Thanks! That's now fixed.

------
wingerlang
Did you make the website? I've thought and tried to make a similar one (angled
style) but never gotten the design nice. Made it yourself or got someone
(who?).

~~~
ezekg
Yes, I made the website. Feel free to dissect it and see how it's built. :)

------
Walkman
I'm curious about the tech stack you are using for this service.

~~~
ezekg
Marketing site is static HTML/JS, dashboard app is in Ember, and the API
itself is written in Rails w/ PostgreSQL, Sidekiq and Puma, most notably.

------
eopkg
What language did you use for the backend?

------
tunnuz
Love the website.

