Monday, October 17, 2005

Offering Money-Back Guarantees

I recently responded to a question from a fellow ASP (Association of Shareware Professionals) member asking about how I offer the 30-day unconditional money-back guarantee on my products. I figured that this is fairly useful information and want to share this with other shareware developers.

When people purchase my products the payment processing provider (I use SWREG) calls my key generator which issues the customer a 55-day time-limited registration key which unlocks all of the features in the product (Complete Time Tracking is fully functional in trial-mode as it is a long-term use product but my other products such as Mozzle Domain Name Pro are feature limited as they have significant short-term usage benefits and I, perhaps incorrectly, want to encourage people to purchase for full functionality). This registration key gets the customer using the full software immediately - customer happy.

If the customer requests a refund within 30 days I thank them for their interest in the product and welcome them to re-purchase at a later date should they change their mind (read: realise that they don't get it for free forever). If after 55 days they are still using the product I "take it back" so to speak when the temporary registration key expires.

Some time after 30 days I send the customer a permanent registration key. This key will not expire and I state that they should use it if they need to re-install the product in future. I typcially process 5-10 permanent keys at a time to save time and have a semi-automated system to make this only a few minute’s work.

Why 30 days for the guarantee? No customer has mentioned the money back guarantee (positively or negatively), other than when requesting a refund, however marketing experts insist that it does help with sales and that the longer the guarantee period the better it helps with sales and the less likely the person is to request a refund. I chose 30-days because it is fairly standard and means that it isn’t too long before I send out the permanent registration key (less likely that the customer changes their email address in that time).

Why a 55 day temporary registration key and not 30? If it were 30 then every day I'd need to be checking which permanent keys I'd need to send out so that there is no "down" time for the customer. 55 days makes the frequency flexible enough to allow me to concentrate on other product and business matters when required, though I try to keep the period as close to 30 days as possible. Having a longer period also allows for more relaxing vacation periods where I perform remote support by periodically checking and responding to email from Internet cafes if travelling.

A separate reason for issuing an expiring registration key, rather than a full permanent key when the product is purchased, is to protect against fraud and leaked registration keys. If the order looks suspicious (likely fraud, often purchased using stolen credit card details) then I have time to investigate further to find that the order is legitimate, is fraud and I refund the purchase (except in the case of "Verified by Visa" and "Mastercard Secure" purchases where the money can be kept) or unclear and I can optionally delay sending the permanent key to wait-out prompt charge backs.

How many people request a refund? I did a quick check of the last 8 months and refund requests for Complete Time Tracking are quite low at around 1 to 2%, and for Mozzle Domain Name Pro a bit higher at around 5% (mostly because of problems released with a couple of builds during this time).

Recently on the ASP newsgroups there was a short discussion of the design for my Complete Time Tracking web site. One person reported that the first thing that caught their eye when looking at the site was the guarantee logo (which is displayed on every page). That's good to know. I specifically wanted the guarantee to stand out, be clear, open, unambiguous and welcoming and would recommend not to add onerous (if any) conditions or hide details in fine print as in my opinion it negates the guarantee and can even be worse than having no guarantee at all.

The only negative thing that I have experienced with the dual temporary and permanent registration key technique is that a portion of customers, around 10% at a guess, either ignore or don’t receive the permanent registration key email (some causes are aggressive SPAM filters, or the customer changed email address or used an infrequently checked secondary email address for their order) . Eventually the customer asks where their permanent key is so I explain when it was sent and to which email address and then re-send it, often to receive a thank you reply. No customer has really complained about this.

In hindsight I would not change the way that I handle and process my orders, generate and send registration keys or the money-back guarantee. In my opinion this system works well.

Monday, October 10, 2005

Tucows Changes Rating Guide

Tucows has modified their rating guide (at least for Windows programs but it also appears to be modified for other programs). The public rating guide has not been updated yet. You will need to log in to the Author Resource Center to see the changes.

The biggest changes are in the Overall Evaluation sections. The cost vs. value and reviewers recommendation have been changed from 3 points to 1 point and the reviewers overall impression has been increased from 5 points to 10 points. Minor changes were made to the installation, customer support, file size, and author home page sections. The multimedia demos section has been removed.

I have updated the Tucows Rating Calculator with the new rating guide changes. See how your application has been affected.

Thursday, October 06, 2005

Tucows Rating Calculator

I've developed a Tucows rating calculator, a simple and effective way to self calculate your Tucows rating and see where you need to improve before submitting your application or update for review to Tucows.

The calculator is based on my interpretation of the Tucows Rating Guide (explained in more detail within the Tucows Author Resource Centre) and presents a simplified set of selections for each section of the guide to enable you to quickly self-assess your application.

Comments or personal feeback are greatly appreciated.

Wednesday, September 21, 2005

Help Files and Technical Documentation

I recently released version 2.4 of Complete Time Tracking. It was a fairly major release (despite the .1 version number increment) as with the update, which contains more than 30 enhancements, I released a new Professional edition for multi-user time tracking (the previous incarnation is now known as the Standard edition).

In light of this I am about to release a new web site for CTT which is a big improvement over the current site, containing more information, better layout, clear feature differences between the Standard and Professional editions, streamlined download and purchasing and so on.

Both of these efforts required a great deal of technical documentation. I do not claim to be an expert in technical documentation but here is my 30 second view and a few tips.

General copy (text) discussing product features should be written with the style "what not how". For example, you might write "Security access to more than forty features can be configured for each user" instead of "You can configure security access to more than forty features by selecting the user configuration option".

Conversely tutorials and instructional copy should be written with the style "how not what".

Web sites promoting your products should typically be written using "what not how", though it is often worthwhile to use "how not what" on FAQ pages and in online feature tours and video demonstrations.

Help files and user manuals usually contain a combination of the two styles. Users want to know both what is possible and how to do it.

A quite useful book for writing technical documentation is Microsoft Manual of Style for Technical Publications, which outlines which/what word forms to use, such as which vs. what, login vs. log in, can vs. may, when to use capitalization, guidelines for writing headings and subheadings and much more.

For help file creation I can highly recommend Help and Manual. Version 4 was recently released and contains some great new features. From the one help file project you can generate professional looking help files, PDF or MS Word user manuals, browser based help and more.

In all cases try to get someone else to review your copy. What sounds ok or is understandable to you might not be the case for other people. Take the following case as an example.

A user of Complete Time Tracking recently queried how to create categories. It is described in the online help but in my "how not what" email reply I said "Select the Configure Categories button on the toolbar...". The user replied "What is a toolbar? I only see some buttons along the top but nothing saying Configure Categories." The button icon and tooltip hint might not be as intuitive as I first thought. Perhaps I should have described how to perform the steps using the menu instead.

Sunday, September 18, 2005

Programming Languages and Popularity

The following information provides a glimpse of the popularity of various programming languages, though not strictly from a shareware development point of view.

Tiobe Software maintains an interesting Programming Community Index. This index "gives an indication of the popularity of programming languages" using results from search engines when searching for web pages about the programming languages.

The September 2005 results show the top ten most popular programming languages to be:
  1. Java (22.4%)
  2. C (19.2%)
  3. C++ (11.2%)
  4. Perl (9.3%)
  5. PHP (8.9%)
  6. Visual Basic (6.5%, not including VB.NET)
  7. C# (3.3%)
  8. Python (3.0%)
  9. JavaScript (1.8%)
  10. Delphi/Kylix (1.7%)

VB.NET came in at number 15 with 0.7%. It should be noted that the rankings in the index likely bias languages that have been around for some time such as C and C++ over newer languages such as C# and Python. The (ratings) column in the index shows the trend over the last 12 months.

For comparison I performed a series of searches at and to gain an insight into what skills are currently being sought by organizations and hopefully generate more of a "current" popularity than the index above. I also included VB.NET. The most sought after programming languages in jobs with relative (comparable but not absolute) job numbers is shown in the following list:

  1. Java (1284)
  2. C++ (438)
  3. C# (213)
  4. VB (119)
  5. VB.NET (90)
  6. PHP (55)
  7. C (51)
  8. Perl (43)
  9. Delphi/Kylix (18)
  10. JavaScript (7)
  11. Python (2)

This is largely what I would have expected.

A poll at asked "What language do you prefer to use for games?" The top six results from 994 votes were:

  1. C++ (76.6%)
  2. C (6.33%)
  3. C# (4.12%)
  4. Java (3.62%)
  5. Python (2.21%)
  6. Visual Basic (1.6%)
In October 2004 asked "What is your favorite programming language?" Of 1206 votes the top ten results were:
  1. C++ (24%)
  2. Visual Basic (14%)
  3. C (13%)
  4. Java (10%)
  5. Assembly (6%)
  6. Delphi (6%)
  7. Visual Basic.NET (6%)
  8. C# (4%)
  9. Basic (3%)
  10. Pascal (3%)
So which programming language should you use for your next shareware application? That's entirely up to you, though it will largely be determined by:
  • What language(s) you have experience with.
  • What kind of application (for example general desktop, web service, game, database) you are developing.
  • The information and community support available for the language.
  • Current trends.
  • Any specific frameworks or libraries that you need to use.
  • What operating system you are targetting.
  • Whether you need to provide a plug-in or other interface to your application.
  • The extent of distribution of the .NET framework redistributable (runtime).

Though some shareware developers are willing to switch languages for a new product and some are changing all future applications to be written in languages such as C# and VB.NET, most stick with a language that they already know.

Thursday, September 15, 2005

Getting Started

It can be difficult to get started as a shareware developer. A large proportion of shareware developers are one-person operations. The ASP September 2004 Demographic Survey reports that 65% of the 353 members who participated run their shareware business themselves. A further 26% of shareware businesses were reported to be run by 2-4 people.

Being largely self-taught, shareware developers need to conduct a lot of initial research. In addition to writing code, which most shareware developers already have some experience with, shareware developers need to learn about web hosting and development, creating installation programs, writing help files, graphical design, writing license agreements, marketing, product pricing, how to provide effective customer support, software licensing and protection, software submission and distribution, advertising, search engine optimization, and payment and order processing.

Some of the work involved in establishing and growing a shareware business can obviously be outsourced. Graphical design, web development, marketing and search engine optimization are commonly performed by hired guns, but in the early days many shareware developers tend to take on these roles themselves.

Other than a few core things that you must learn before developing and releasing your first shareware application I believe that it is relatively simple to start a shareware business. Strive to learn as much as you can and over time you will acquire invaluable knowledge and skills that enable you to streamline your processes and improve your products.

Over time I will be covering a lot of the above knowledge areas and hope to provide some interesting details and my views on shareware development for new and experienced shareware developers.