Show HN: Keygen – A dead-simple software licensing API built for developers
keygen.sh
keygen.sh
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.
Whether it's a lot or not depends entirely on how much you're making. For someone who has a $500/year side project $288 is half your revenue. For someone who has a $50,000/year side project $288 is trivial. If you're marketing to people who haven't yet launched then most of your customers are in the first group - and that makes your product sound quite expensive.
If I had the need for your product I'd be much more likely to use it if the cost was something like $1/user/month, capped at $30/month.
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.
Secondly, I agree that it's far too much money for a weekender level. Bear in mind that most weekender projects will be using free tiers at various providers. This could easily swamp all other outgoings combined.
If you really do want to capture the weekender market I'd probably suggest cutting the cost to 1/3 of current and billing annually.
Think about the time savings. If it saves you more than 10 hours of development and maintenance time, pays for itself, even if you don't have a single customer.
How many pointless purchases do we all make each month? I buy 2-3 domains per month for ideas. 90% of them just sit there.
I have 4 droplets at digital ocean just sitting there and 1 actually being used. Its the opportunity cost of losing them.
That is why God/IRS invented write-offs. If you use it, great, if not, well at least it's pre-tax!
I find that developers are especially prone to this even with salaries that are typically 50% or more higher than their national averages (500%+ in India). With all this extra disposable income, we should be spending it supporting other developers and using the tools that they make to make OUR lives easier!
But my DO droplet, which runs all my websites, costs $10/month. All the other incredible stuff I use costs 0.
Also, recurring costs add up over time. A long term commitment to a company has unknown ramifications. My income from a new project is 0.
Now that I've been forced to think about it, I probably wouldn't pay $5/month - because (as has happened to me in the past with services I relied on), the price could easily get jacked up. And then I'm committed, or have to back out some code and implementation.
Long term external commitments with companies of unproven track record and uncertain costs make me nervous.
My new plan is to see if I can solve this reasonably well myself (at much higher development costs) and only use keygen or something like it if I really have to.
Which, btw, is exactly the thought process you don't want your pricing to instigate.
Your license server costs $288/year. I'll need to continue using it as long as my software is in use—lets say 5 years. The service will cost me $1440 over that period.
Over that period, I'd be paying you 72% of my gross revenue.
If I only sold 100, then it would cost me $440 more than I made on licenses.
If I sold to the plan's max of 1000, your service would cost me 14% of my gross revenue ($1440 of my $10,000 gross) over that five years.
A pricing scheme that closer resembles $x/license (forever) is something I would be more interested in.
One way around this "limitation" is to store somewhere in the machine that it was activated already, and then you can cancel your service at keygen.sh. Then if you make your sales all in a single month, you only pay $24 (or roughly 1%).
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.
We built our own stupid-simple licensing system. True, it wasn't that hard, but it would totally be worth $100/mo to have this maintained by somebody else, so we could focus only on our product.
Their competition (FlexLM, etc) is horrific. This looks much better.
On the other hand many things use FlexLM only to provide node-locking which is thing that it can do, but is to some extent an afterthought. The thing was originally designed to be used over network to provide floating licensing, with some minimal resistance to cheating and cracking.
In fact it seems that it's original author(s) (wikipedia says that the whole "team", but it mostly looks like one guy) got fed up with managment and marketing so much that he went on to implement and sell RLM on their own, which mostly seems like slightly better FlexLM without completely nonsensical features.
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
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.
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.
I myself pay for software I know I could of looked up a crack for, but being a developer I know how much effort software development takes I opt to either find an open source alternative or buy the product if reasonably priced. If I can't find a decent alternative and the price is poor, I probably wont use it, whatever it is.
Also, that user is running some random binary from the internet just not to pay. Without that crack, you would never have had that user.
As somebody who has implemented a custom licensing server it becomes a trade off between ease of use, ease of maintainability and resistance to cracking.
>It seems trivial to issue your own license tokens and have clients check in with your website for an OK / BAD response.
It can be trivial if all it does is tell you if a license is valid or not. But when it comes to adding/removing features in the application based on a single license key and also dealing with offline licensing it becomes less trivial. On top of that, you need to make sure your licensing server doesn't go down. It is just as easy to pay to have it taken care of for you.
But maybe I’m missing the point?
There is:
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.
It seems to be mainly for APIs that provide a service, not for protecting client-side applications.
I'm not so sure about that, right at the top of the page is has the line: "For licensing desktop apps, on-premise software, and other digital products." That certainly sounds like it is meant for client side applications.
The FAQ seems to indicate that it's meant for client side apps as well.
This is what online games do with DLC (downloadable content).
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?
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.
But they will shut down any out-of-band payment options. There is nothing even remotely fine about this.
Regarding the missing languages e.g. Obj-C, Swift and Java--that's simply due to me not having put in the effort to write examples in those languages (I'm not fluent in any of those).
I would politely suggest that you rethink the wording on this? I see now that it's addressed in the FAQ, but you're hitting it up front as a top marketing item. Perhaps specify macOS App Store, so that people don't get confused.
I can't understand how you can talk about this product as being any app store alternative if you can't provide examples in the languages that people use to write apps that go in stores.
No one is writing macOS apps in Python or C#. Well, a few people are, but not people who are charging.
I'm not trying to be a pedant, and I think this is interesting. I just can't wrap my head around what you're trying to do or who you're doing it for.
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!
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.
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!
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.
Care to bet money on that? That's rather shocking hubris.
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.
However, does it run afoul of acceptable SEO practices? Namely those covering autogenerated content.
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...
Sounds prohibitively work intensive in the extreme.
[0] https://www.cuckoosandbox.org/
[1] http://www.covert.io/research-papers/security/Automatic%20An...
Very, very nice-looking site, though!
Is there a name for this phenomenon? The creators of Angular fell victim to this effect. They changed around the naming so that "Angular" is supposed to refer to versions 2.X+ and "AngularJS" refers to versions 1.X, but unfortunately the search engines are all poisoned such that "Angular" searches lead you to 1.X results, etc...
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
Support! Offering support when things go wrong is huge.
PS. Internet connection is frequently not available for enterprise software.
I don't know. I'm just describing an existing problem that I would like to have a solution for.
>a hosted web form that generates a key
Not just generates a key, but also ensures that the use pattern complies with the licensing terms. It's the same API but on-premises.