Raise your prices.<p>I can't be alone in thinking that these prices are <i>insanely</i> low when considering the market. If you're selling to working programmers, $9.99 a month is a frivolity. I pay more than that for Netflix. For a business expense? Your $24.99 plan should be the <i>entry</i> point.<p>You should have a higher tier. A <i>much higher</i> tier, in fact, like $350. You're targeting agencies and studios at this point. It's still under the ~$500 that requires approval, but there are absolutely businesses out there that will just sign up for the highest tier they can process, because it's a status thing or "they may need it". You won't get many signups at this price, but even one will replace <i>35</i> signups at your current lowest tier. Heck, more, because higher-priced customers will churn less and require less support.<p>Consider dropping your free tier and just relying on your free trial. You're targeting businesses and working programmers. They have money, so a lack of money won't be the reason they choose not to use your product, only product/customer fit.
This is nice, but I would never put a piece of code on my property that breaks the user experience (after a few seconds) when a third party service is offline. It's even worse because it causes a highly correlated failure vector across all my products. Imagine your servers going down (for whatever reason) and _all_ my customers calling me because their websites are broken.<p>Additionally, defaulting to shutting down the app when it can't reach your servers breaks all sorts of offline features an app may have.<p>I would strongly suggest to default to doing nothing when the script can't contact your servers. Alternatively you let me configure an HTTP endpoint that will be pinged when it can't reach you so at least I am aware the service is disrupted.
From looking at the JavaScript snippet that is provided, it looks like I can get around the validation by simply creating a cookie who's contents is "validated=yes" before the qeys script is loaded.<p>EDIT: The part of the snippet in question:<p><pre><code> window.addEventListener('load', function(a){
document.cookie.indexOf('validated=')<0&&v();
});</code></pre>
This definitely seems like an interesting product, but if you're an anti-piracy company then maybe you shouldn't be using a pirated font. If you check the Product Sans CSS file you're including, you'll see there's a notice that the font is not open source.
From the FAQ section:<p>> the thief<p>> the code they just stole<p>Uh. I know this is extremely widespread to call it so, but copyright infringement isn't "theft" or "stealing".
Seems it would be as effective as cd key protection or DVD protection - meaning anyone doing the copying likely won't be affected and attempts to tighten the grip will probably hurt legitimate customers.
> by the time the pirate realises that licence validation is in place, it's too late for them<p>> we strongly recommend to let our JavaScript file blend in with the rest of your application [..] to make the code responsible for validation as difficult as possible to find and break<p>This smells much more to security by obscurity than an actual licensing solution.
`[...]make the code responsible for validation as difficult as possible to find and break` ⌘+W<p>Seriously though, this seems like an convoluted way for small businesses to resolve trust issues with their clients.<p>I mean, if you really want to do this, why not make it incredibly simple and just ping a server with the domain names the web app is being requested from. Do it all silently and then let the IP owner decide what to do about it. Why shut the site down and risk embarrassing, and potential trust destroying, situations arise from false positives?
This breaks any existing js that sets window.onload if the qeys script is loaded after it. Usually it's better to do window.addEventListener('load', ...) so you don't overwrite anything.
"* Unlimited number of lincences"<p>Also, your privacy policy makes no mention of what data is included with validation requests, and what you do with that information. GDPR is still very fresh, and if my app is passing every URL data to a third party, that sounds like it could be a problem.
I feel like i'm missing something obvious here. This is for "webapps" which have been "licensed". Who is running licensed webapps without some form of user account? Either a login or an API key, which can easily be turned off if the person stops paying. If i have that, why do i need this? If i don't have that, haven't i just totally fallen down on the job of controlling access to my system?<p>What am i missing here?
I am so confused.<p>> Besides, we strongly recommend to let our JavaScript file blend in with the rest of your application's JavaScript. Webpack, compress and uglify the best you can, to make the code responsible for validation as difficult as possible to find and break.<p>Ok, so this is a solution to <i>detect</i> (some of) the sites that use your JavaScript code without approval, not a solution to prevent them from doing it (since it can be easily blocked once you <i>know</i> to look for it).
<i>> The instant solution to worrying less about your web applications being copied by the clients you developed them for.</i><p>Is this a problem that happens often?
Question: How about having the option of not blocking but only reporting?<p>Then you can put a use clause in your service agreement and bill your customers according to their use. They've signed that any additional use incurs a cost, but they don't think you know.
It would be nice to have some copy/pasteable snippets to integrate this with my stuff. It is unclear what I should do once I register an application and am presented with a list of keys.
in my mind the only true way to protect against client software ripping is to put all of the protected IP on your service, and make service calls to it from the client application. If the code resides on their hardware... there aint really anything you can do to protect it.