The Business of Software Wiki

A part of Joel on Software, and a companion to the Business of Software discussion group.

Software Time Trials

Andrey Butov

Every once in a while, one of the forums dedicated to the business of software spits up a question regarding the proper duration for a time trial. It has become somewhat commonplace to expect a 30-day duration from a trial version. Some software shops package that up with functional limitations, some don't, but the time trial has proven to be the goto guy for use in a demo release.

But the question remains — how long should the time trial be? Is 30 days something that is used because it has a proven track record, because it's what customers expect, or because developers, after focusing for months or years on building the actual product, simply decide to stick with the norm without giving the business side of their business a second thought?

I'm tempted to say the last one would pull the most weight. Such as the case with user interfaces, payment processing, pricing structure (don't get me started), and even customer support, thought given to the time trial seems to take a back seat…especially with shops releasing their first application.

The naive way of looking at this would be: give users enough time to fully evaluate your product. But this is just the tip of the iceberg — it's what you'd say to someone asking what a time trial is in a nutshell.

The point of a time trial is not to let the user evaluate your software. It simply isn't. You may fool yourself into thinking that the ethics of the business of software dictate a well-defined clause which deems this to be true, but unless someone out there has published a well-defined, well-respected, and more importantly, well-enforced document outlining a software customer's bill of rights that I'm not aware of, you are releasing your time trials to convert them into sales of licenses.

That is the entire point. You are running a business, not a charity foundation.

If you think that the above statement gives you the right to misrepresent the software through a variant of functionality in your time trial which does not actually exist in the full-version of your product, you are missing the entire point. Or perhaps, you simply don't have the proper outlook on what a software sale actually is. A conversion of a time trial into a purchased license is not a one-off transaction. The single downloaded time trial does not map one and only once into a single purchased license. And your business does not become successful through isolated sale conversions.

Your time trial represents your line of products — all of them. The single conversion doesn't map once and only once into a single sale — it maps to all the subsequent sales — of that version, of futures versions, and of all the software you will release in the future. If you cheat your customer by misrepresenting your software with a time trial which doesn't accurately portray your full-application, you are not going to stay in business for much longer.

On a bit of a tangent: sometimes, developers who are just starting out don't grasp this fully. They see a moderately successful uISV owner on the message boards complain that he only made 50 sales this month, and the first thing that comes to their heads is "50 sales! I wish I had just 1 sale!". This was me. I defined success for Antair as getting 1 sale. I told myself that if I ever make 1 sale, that's validation enough for me to continue doing what I'm doing. This is a bit naive. Eventually, you will realize that 1 sale, or 100 sales, or 1000 sales don't make a lick of difference if they come about as sporadic events — perhaps because of a promotional event. Selling consistently, month after month, with a steady revenue stream is what you're after. Even if it's 10 sales a month, a consistent (perhaps recurring) revenue stream brings much more of a balance and potential for growth for your company than 100 sporadic sales that you can't track or duplicate.

Anyway, back to the time trial.

I'm sure that 30-days started off for good reason. I don't know what that reason was — perhaps something having to do with expected duration for physical purchase orders for certain customers — perhaps because of the way accounts payable departments work.  What I do know, is that most small software shops do not peddle their wares to firms that expect to be given on-site sale pitches, followed by physical contract signing, and payment based on a 30-day invoice. Most trials for software products are 30-days, because most prior trials were 30-days, and no-one bothers giving it a second thought.

If you stop and give it some thought, you'll find that many uISV owners who are considered to be 'successful' offer something different than a standard 30-day trial. Before you begin thinking about the duration of your next time trial release, go walk your dog, take a nap, or do anything else unrelated to the product. Afterwards, forget all your emotional connections to your software, and start thinking like a potential customer.

If your product is a non-essential utility, a utility with a low price point (~ $10-$15), or something that is used as a one-off in order to satisfy an immediate, and short-term need, going with a 30-day trial will not give you the leverage you need to convert the trial into a sale. Instead, either implement a much shorter time trial, or remove the time limitation and implement functional restrictions instead. For utilities like format converters and other things which offer a "generator" like functionality, remove the save and load facility. Your customers can still evaluate all of your features, and the trial will still be there for evaluation 2 months later after the customer has evaluated all other similar packages and found that they were all crap.

Printer Friendly was initially released with a 30-day trial. I can't say that I've put much thought into this at the time. Honestly, I can't say that I put any thought into the time trial at the time. Conversions were low. From the customer's perspective, here's why. Printer Friendly is a long-term use, non-essential, one-off need application. The trial is installed, and the person tries it out once. If she hates it, she uninstalls it and you never see the sale — probably your fault — she hates it for a reason. If she loves it, does she purchase it on the spot? No. Stop that thinking right now. Think like a user of the software. If you download a piece of software that converts your .GIF files into .JPG files (for whatever reason), or takes a screenshot of your desktop, you are downloading it because of an immediate need. If you only need to use it once, you will never pay for it. It doesn't matter how long the time trial is. It will never be converted to a sale. I used it, it did the job (after all, the save and export functionality is there for me to use), and I forget about it. Perhaps 7 months later I'll get around to uninstalling it if I'm browsing through my application list.

I dropped Printer Friendly to a 14 day trial, after which sales increased. Then I remove the time limitation entirely, and implemented functional restrictions. Now it's selling steadily. The customer thought process remains the same…only my trial version strategy changed. From the customer's perspective: it's not an essential utility, and I may use it once or twice a month. The third time I get around to clicking on that icon, if it shows me an expiration dialog, I'm going to say 'screw it', and print the page as is. But if Printer Friendly is always there…if it is always available, and every time I get around to using it, even a year after I installed the trial, it works, but keeps reminding me that the full-version has more features, or a better printing algorithm, or some other optimization, I will finally get around to spending that $15 bucks. I mean, why not? I used the thing 40 times over the past year. It has worked every time. I know I saved money using it, I will purchase it to get those extra features and enhanced functionality. Even if I have no time to buy it right now, I can forget about it, and it will still remind me 2 months later to purchase it, when I do have the time to do so.

At the other end of the spectrum, are long-term, essential need, constant use, applications. For products like databases, helpdesk applications, bug trackers, and anything else which 'holds' data of some kind (including calendar or scheduling data), a longer time trial clearly serves best. After 45 days, that trial version of the helpdesk application I downloaded has over 100 support tickets. After 60 days, my trial version of a bug-tracker has 200 bug reports — all prioritized and cross-referenced to external documentation. The application works well, there are no obvious bugs, and it already holds all that data for the company or the project. Now it's showing me a dialog box informing me that it's about to expire. Why would I not buy a license? It would be more trouble for me to evaluate or purchase another product and start transferring all my data out.

I believe that game developers made the most headway into using unique time trial implementations. For games, a time trial doesn't make any sense at all. In a game demo, the demo should end immediately before the customer reaches the red line of boredom. This line exists in every game. Even if it's the best game out there, you have to stop playing at some point. Many game development shops release a demo version which is entirely different from the first level of the full-game. This is because the first-level of the full game would not serve well as a trial version for the game — it's too boring. Perhaps it's even just a tutorial level. What the demo needs is a custom level which makes the player salivate. It doesn't matter if the demo is 10 minutes long, or 5 hours long, as long as at the end of it, the player must know what's behind that door, and the door only opens up in the full-version of the game. It's the same cliffhanger strategy that television shows have used for decades.

Not to be too hypocritical, but I set a 30-day trial with my most recent release — the Antair BlackBerry Spam Filter — with no functional limitations. A spam filter is closer to a helpdesk application than it is to a one-off utility. What it does, at every instance of functionality, is a one-off piece of work, but the effect on the customer is cumulative — no spam for 30 days…then…boom - an inflow of spam again, and a message box stating that the spam filter has expired — please pick up a license. In this case, I went with 30 days, but the important thing to note is that the duration itself is almost irrelevant. It wouldn't matter if the trial was 10 days or 60 days — the effect of filtered spam vs. non-filtered spam is noticeable, and that is what brings the sales — not the duration of the trial.