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.
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.
$288/yr is not that much for something that helps you make money
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.
There are two issues, for me. Firstly, a monthly price in dollars can be annoying for very small projects, as it's quite possible there will be a relatively large flat currency conversion fee from a bank. Paying that once hurts less than twelve times, even if it's not all that much money.
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.
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.
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.
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.
If I sell 200 licenses for my desktop app in one year at $10/pop, that's $2,000 in my pocket.
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.
I can't speak for the founder of this company, but I would assume their product goes more toward the yearly/monthly recurring software licenses, not for a one-time purchases.
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%).
Appreciate your feedback. I'm not at all married to the current pricing, and I believe there's room for a smaller plan so that I can support developers who aren't making a lot with their app or are in the process of building it. I'll look into it. :)
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!
You can justify it, of course. But when comparing it to other free things out there, eg letsencrypt or as OP said npm for package management or editors like vscode and you still have to take into consideration that some integration time is still needed then keygen.sh feels very very expensive.
I get the argument, I really do. I was young once, and would reinvent any and every wheel I could just to not pay for anything! But at a certain point everyone grows up and starts to value their time more than a few dollars (typically when you get a family started).
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!
These are all fair points, as is the one about not comparing a product with an open source project.
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.
Hey, just an update! I shipped a new value-based pricing model today (https://keygen.sh/pricing) after getting feedback from HN as well as others. Would love to hear your thoughts!
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.
>>> 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
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.
Maybe for a regular single user who probably wouldn't of bought the product, but in an enterprise company it's a whole other story.
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.
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.
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.
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.
I never knew anybody who wasn't able to get around licensing AND downloaded cracks. Cracks are (were? is that still a thing?) just time savers. If you can follow some tutorials on replacing a binary with an edited one, you are brave enough to learn how to edit it yourself.
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.
It depends on who the customers are. We have license checks at my company, and they would be rather trivial to circumvent. But they are there to keep the honest people honest, not to stop a determined adversary.
Just because it is there doesn't mean people will use it, especially when you are creating B2B software. If a company was found using cracked software that would cause big problems for them. It is cheaper for them to just pay for the software.
I sell a niche desktop application to engineering companies. They self-police themselves pretty well - we're really not concerned with them cracking our software at all.
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.
FlexLM is horrific and does terrible things like stashing data in unused/unformatted areas of your disk as well as dropping litter all over the registry and filesystem. I have to use Tableau which I actually really like but because it uses FlexLM that shit will never touch my bare metal.. VM only.
The part that does this is not FlexLM itself, but safecast with which it is frequently bundled, but many specialized engineering products use only FlexLM without additional DRM layer (FlexLM itself is originally meant for Unix and mostly portable, Safecast is probably Windows-only).
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.
>The hard part with software licensing is making it resistant to cracking.
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.
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.
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.
> 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.
I like this idea. Offer a fully working copy with only a fraction of the features the licensed copy has. Features are "staged" so it builds on previously downloaded content and every download is tied to a unique public key.
This is what online games do with DLC (downloadable content).
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?
The FAQs address this, but just to be clear: Keygen unfortunately (as you said) doesn't work for mobile apps stores, due to Apple's (and Google's) developer terms. When referring to the App Store, I mean the macOS App Store i.e. for desktop apps. I'm advocating selling desktop apps independently outside of the App Store, which you can most assuredly do. :)
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.
It hasn't been an issue thus far, but I'll see if I can make that clearer. I'm not implying that developers are writing macOS apps in Python or C#, but they are writing Windows apps in C#, and they're writing cross-platform desktop apps in JS, as well as licensing servers and on-premise software (and that includes a lot--WordPress plugins, software like Sidekiq, etc.) in all of those languages. Keygen can either be integrated directly into a product e.g. macOS/Windows app, or it can be integrated into a server to transparently handle licensing (nobody can infer that you're using Keygen in this case using something like Little Snitch). Like I said before, there's a simple reason Swift and Obj-C aren't up there: I don't know them very well; I'm in the process of learning Swift, so that will change soon though.
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.
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.
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.
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]).
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!
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.
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?
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. :)
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.
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.
> Not only is it pretty un-googleable due to other, older results likely taking priority
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...
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.
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.
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.
Not really... but what's the point of starting a business if you don't believe in it? I wasn't stating it as fact; it was more of a 'wouldn't this be cool' statement--sorry if I came off wrong.
If that's the case, integrating Keygen server-side using a custom domain e.g. licensing.example.com would get around that, but so far this hasn't been an issue at all.
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?
Customer logs into a web portal and pastes some hash generated by his/her instance. Then downloads a generated license key for offline use. Alternatively, a license manager installed on-premises that dispatches licenses locally based on a master license key.
PS. Internet connection is frequently not available for enterprise software.
What would be the use of Keygen, then? Not sure if people would pay for what would essentially be a hosted web form that generates a key. I just don't see what value Keygen could bring in that situation, especially considering my initial product is an API. Regarding enterprise--I'm actually focusing on small- to medium-sized businesses right now, not enterprise; offering on-prem plans is as far as I've gone into enterprise-land.
No problem, just trying to dig a little deeper. :) I do offer on-prem installs of Keygen in a dockerized container i.e. an enterprise plan, so it could most definitely be installed in a locked down network. Other than that, you could also set up a policy that requires licenses to 'check-in' at an interval e.g. once a month to remain valid. You could then set up a web form they could visit that let customers 'check-in' all of their nodes somehow and purchase additional licenses if needed. (Just brain storming here.)
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. :)
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?).
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.