Software Development – Implementing a Self-Destruct Feature in Free Trial Software

developmentsoftware

There is the ongoing argument of free trial versus a freemium model (that is, a free-for-life version of their software with restricted and/or stripped down features) for allowing potential customers and users to test run their product. Upon my research, I can conclude that the free trial is the way to go on both for the benefit of the user experience of the individual using the software and for the benefit of the vendor in both aspect of sales and maximizing usage. There are many factors for a free trial software that can greatly maximize user usage like the length of the free trial.

One keyword that reoccurs on my research for "freemium" is "frustrating". Many individuals chose to uninstall the software instead of having to use a piece of software where some features were unavailable to them. At the same time, these users never had the chance to use the "paid" features. Unbeknownst to them, and hidden by the very own vendors who are selling the software, they don't know and cannot know what benefits the Pro features will bring. Without first having to use them, a user will not know they have the feeling of "needing" something. Which brings me onto my next point of a free trial model.

Some opinions of a free trial user is "I cannot imagine using this software without the Pro features." This goes back to the point of "the user not knowing they need something until they first understanding the feeling of have." Those that have had 14 days to use a the "full" version features said they cannot imagine not having or using the features provided there. So when fourteen days were over, they were more likely to dish out money than someone who's never experienced the full features. The length of the free trial is also an important factor is creating a lasting impression on users. In an experiment conducted by Visual Website Optimizer, they noticed that for a 14 day free trial versus a 30 day free trial, while the number of sign ups and installs were the same, the usage for the 14 day trial increased 102%. This, of course, in turn increased their revenue as well.

Another very important point to mention is that "offering a useful and fully functional free version of the product" is VERY IMPORTANT. Fully functional free trials are effective in getting media coverage, and this publicity for new software and/or software vendors are fairly crucial.

One other relevant aspect is the importance for users to give feedback. Consider, in the fully functional time-limited free trial, the ability for users to give feedback.

One other feature important for our software is the need for telemetric data, that is, quantitative and comprehensive data on how a user uses our software. Some of usage statistics may fall into a legal grey area, as laws are different depending on the location in the United States, and the world. One way to combat this legal issue is to have an opt-in feature for gathering anonymous usage statistics. An opt-in feature would mean giving the user an option to turn off statistics gathering and at the same time, the user must be very well aware of what the gathering of anonymous usage information does. It is important to make it CLEAR to the user what data will be collected, what "we" will be doing with it, and make it easy to turn off any time, including allowing them to change their mind for turning it on or off. For more detailed statistics, like tracking individual activities of users, it could lead to legal issues. The Eclipse IDE logs detailed usage statistics, but it does it by the full consent of the user. We may have to potentially prepare a consent form with our legal team.

The Eclipse Usage Information Collection collects this information:
1. Plug-ins that are started by the system.
2. Commands accessed via the keyboard shortcuts and actions invoked via menus or toolbars.
3. When the "view" of the editor is given focus.
4. System information like the version of the software being used, the operating system being used.
5. Description of internal errors.

Kill Switch

A kill switch for our software can be managed logging the initial data, encrypting it with a salt, and whenever it's an invalid date, that is, the user tried to change it, it would disable the software. Another option is to have internet authentication on install, log that date to a central web database, and check the date every time the application is opened.

On disabling the software, we can delete vital DLLs. The option of having to pay to generate a report cannot be considered.


I am interested in implementing a free trial version to my existing software. I plan on having the trial last 14 days. Upon the 14th day, my software would prompt the user to either pay for the paid version, or have the consequence of not being able to use it. The free trial version is entirely unlocked, meaning all paid features are there.

However, my dilemma is about the "best" way to implement what to do for an end-of-trial solution. Do I delete vital DLLs? Have a user authentication system upon installation or use? Encrypt the initial time and date of use with a salt, and if it's an invalid date (AKA they try to change their initial date), disable the software?

I am interested in knowing what are some effective measures of disabling software.

Best Answer

There are two issues here - one is a programming problem, and one is a business problem. For the second one, asking programmers about business analysis is about as good advice as you can get from your local bus driver; which is to say it may be good, or terrible, but you aren't asking experts so assign no inherent weight to any of it. (As an aside, one of my bus drivers often gives me good ideas.)

But as for a programming problem, the downside is that it seems most people don't like the idea to start with. There's lots of good reasons for this, but they aren't really important here. Sadly, we are also in some ways a terrible group of people to ask, because by virtue of our position and knowledge most of us are pretty darn good at pirating software to the point that we think it pointless to try to implement trial measures at all!

The fact is, your core issue is a business analysis and sales experiment problem, and there is no answer save from getting to know your customers and experimentation. It doesn't sound like you already have a big pool of customers to talk with about their product sales pipeline and how you can implement trial software to improve it, so one must understand that we are now in a position of stabbing blindly in the dark. The first step to working in a dark room is know you are in one!

So, start somewhere. The goal is not the right answer, because I can only 100% guarantee one thing - you aren't going to start with the right answer. But start we must.

Give Your Customers a KISS

Also, "keep it simple, stupid." Or, from a programming methodology, "try the simplest thing that could possibly work." Then go from there.

So, when installing get a date. Store it. Get your data on installs and usage, and bask in the warmth that data analysis can bring. Disable whatever part of the software you want when the trial expires - I suggest if (trial_expired()). Then adjust.

First of all, get good data. Are you expecting to provide updates in the future for your software? Then if someone tries to beat v1.0, don't worry about it.

The easiest thing is uninstall the software, then reinstall it. New trial period (because your software deleted that old date). Do you care? If v1.0 is soon to be updated, then I strongly suggest you get a way to find out if this happens - but don't try to stop them (yet). It's like people who take 2 mints instead of 1 - it's just a mint, let it go. They probably weren't going to pay you for it (yet), anyway.

How? Well, in Windows this was usually done by shoving random orphaned keys in the registry and weirdly named files in various common installation directories. Your installer would explicitly pretend they didn't exist and just leave them there. The level of computer sophistication this requires to defeat is vastly more than uninstalling.

But if you don't try to stop someone from reinstalling, then you get data you are going to need. They aren't robbing your store, here - they are giving you a valuable opportunity to study a potential customer. Use it to tailor your marketing, software help prompts, email campaigns, 'special offers'. I'd try detecting the event and then, a day later, sending them a key they could enter into the program to extend their trial until next month. You might find a method that turns them into paying customers, or not; no way of knowing ahead of time!

This seems trivial, but lets face it - do you really need anything more than that? If you are collecting data, that's worth money to you. You'll probably want to spend time on making sure emails are good, designing in-software messaging that you can update to guide new users (invisible sales pitches, really), rewriting your app blurb, hammering out bugs that would prevent any sane person from buying your software in the first place, etc.

But the key here is you are communicating honestly and clearly to all potential customers - if you want this, you should pay us. Just because you are being (invisibly) magnanimous doesn't mean this is freeware - you are just going to be smart about it and not drive away customers because they haven't sealed the deal in the first two weeks.

If you think about it, these people are coming in to your store to really look over your product. They are taking a test drive, yet it costs you (nearly) nothing. No successful store got that way by driving out customers who weren't yet ready to buy! Yet we all know if you can get something for free, forever, why pay? So use the best of both worlds.

With each step you take you will be working a filter, and if your software is good you WILL be making conversions with every step. My simple suggestion:

1) 14 day free trial

2) Extend the free trial, no questions asked

3) Offer to extend the free trial again, if they'd be so kind to fill out a short form that communicates to you their opinions of your software so far.

4) Are you sure these people who are still actually using your software won't consider buying it? Find a way to entice them - or at least try to squeeze more info out of them on what you could do to get others to buy. Maybe allow them to 'request' an extension through a form, which your sales staff will kindly grant regardless and then use the info to see if they can deal with any objections they might have to buying your software.

What if this user is evaluating it for use in their entire department? If the budget meeting is next month, do you really want them to be unable to use the software until then?

5) Maybe you cut them off now...and maybe you invite them for a special offer a week later at a discount. Maybe not. Maybe you offer to extend to give a final extension.

These people don't owe you money, so treat them as potential future customers - not thieves, freeloaders, or people who need to pay their bill or get their service turned off. Everyone hates bill collectors, so don't act like one.

Programmatically, let's face it - this isn't actually hard. Use orphaned files to keep track of dates. If you have to have a valid account like through iTunes, this tracking is way easier. If it isn't required, then I would generally suggest you not require it for a first install - never turn people away from the first version because they don't want to fill out a stupid form. People hate forms! And they don't know your software, so why 'pay' to fill out a form if they don't even know if your app works?

On step 2, I'd get a signup/email to extend. Again, programming it is trivial.

3) After 30 days I'd probably require some kind of 'phone home' behavior. If people are going to crack that - like they do - congratu-friggin-lations! You must be getting pretty popular. But don't worry, if this isn't a video game people probably don't care enough to bother, so just change your code in the next version and make them go back to the drawing board.

TL;DR;

#1 Don't solve a problem you don't really have (you aren't Adobe, yet - DRM can be simple and effective if you don't over-think it). #2 Don't ask a programmer when you need to ask a marketer, business analyst, or salesman. #3 Treat your customers as people who might give you a living, not as people who owe you money, and especially not as thieves. #4 DRM is really, really, easy. Just don't think you are going to stop people from using your software who will almost certainly never, ever, ever give you money...at least, not today.

  • I have bought software I've pirated, years later. So don't piss off future customers needlessly, either.
Related Topic