Volume Number: 13 (1997)
Issue Number: 11
Column Tag: Software Business

Distributing Software on the Internet

by by Kee Nethery & Kagi clients, Berkeley California USA

Advice from people who have learned the hard way

All programmers dream of retiring on money earned from a program written in their spare time. They know the coding part and they can envision the retired part, it's the steps between where "magic happens" that are just a bit fuzzy in the dream.

Absolutely the most successful products distributed on the Internet are those that: are good, are usable by the largest number of people, are easy for people to use on a trial basis, and have a compelling reason for people to pay. No one is born knowing how to create such a product or getting people to pay you. While you spend lots of time learning all these skills...

Even if your product is wildly successful and you are earning many times more than your day job, keep in mind that your massively successful product could become obsolete tomorrow and your income could suddenly cease. You and your family will sleep easier if you keep a day job that pays the bills and puts food on your table. Consider reducing your monthly overhead by paying for your home, paying off all your loans, saving money for future large expenses, etc. As you reduce your monthly expenses, you can safely reduce from a full time job to a part time job. When your monthly expenses are so small that you can earn that amount each month by working a day or two as a consultant, you'll know that the day job is not required. Until then, always have a way to pay your bills because the chances are that your first product will need lots of tweaking over a long period of time before it has a chance of being successful. You will not be able to program if you are worried about finances.

The above advice has nothing to do with creating a good product. So how to create a good product. Telling someone to write a good product is like telling them to...

You should write a product that everyone will want to purchase. Well, duh. :-) Write software that others think is better than the competition. One easy way to be better than the competition is to create a product that leverages some expertise or passion that you already have. If you spend idle time pondering some subject area, chances are good that you might be the best informed programmer in that subject area.

You should be able to do a very good job of writing software in your subject area because you know it so well. Within your area of passion and expertise there will be a wide range of products that you could create. Look at the existing products and envision one such that...

Before you write one line of code, find twenty or more people who would want your type of product and ask them what they would want it to do. If you cannot find enough people to give you suggestions, either there is not a big enough market or you need to first figure out how to locate these people. These people will be your beta testers. Once you start to get suggestions from lots of people, consider if this market has money to pay for this kind of software and if what they want will sell to lots of people or just a very tiny segment of these people.

Within your target market, imagine all the people who use your chosen computing platform (for the purposes of this article, Macintosh users). Imagine what percentage of these people share your passion. This will be a small subset, lets say 1 out of 100 of the overall users of that platform, 1%. Within this small subset, you have a variety of product types; single user, multi-user, programming tools, etc.

Software that appeals to your entire market might sell to 1 out of every 10 of the 1% = 0.1%. Server or multi-user software that is shared by many people might sell to 1 out of 20 of the 0.1% group that would purchase the single user version = 0.005%. Programmer and developer toolkits might be used by 1 out of 100 of the 0.005% group that would purchase a server = 0.00005%. When you consider writing a programming toolkit, a server, or a single user product, keep in mind the size of the market and price your product accordingly.

Develop a product that you are expert in AND keep in mind what percentage of the overall potential market your product will sell to. A product that deals with controlling telescopes might get 100% of that market (sell a copy to everyone) and still make very little money as compared to a screen saver that sells to less than 1% of it's entire market.

Your product has to be competitive. Learn about your competition. Buy their products, use them and understand what is good and bad about them. Your product must be the best or you should find a different market. Keep in mind that best does not mean biggest and most feature rich, it means that your testers like your product better than all the others.

Don't be afraid of big name competition, you can beat the big companies. Their teams of salaried programmers are like huge oil tankers that take miles to turn or stop. You are the wind surfer who knows all, sees all, and can change direction in seconds. You are absolutely the most efficient programming team that is possible, one programmer with the complete program in your head and a passion to do it right.

One of the biggest factors influencing Internet software sales is not how well the program performs its function, but how solid it looks and feels. The user interface is critical. A rock solid product with a shabby interface will be perceived as inferior to a buggy product with a pretty interface. People do judge a book by its cover so find someone who can give your product an excellent user interface.

This is the key to Internet software distribution. You want to provide enough functionality for a long enough period of time so that people become accustomed to your product and not having it is not an option for them. The easiest way to do this is to provide a fully functional product that is easy to use and does things that people want. Of course this is in direct conflict with...

For any product distributed on the Internet there is a slider that goes from "Full Functionality and Payment Optional" to "No Functionality until Payment Received." Finding the optimal balance between these two extremes is not easy.

You want to provide enough functionality for a long enough period of time so that people become addicted to your product and are enticed to pay. How you entice them to pay depends entirely upon what kind of product you have. Spend time brainstorming with friends and your beta testers on where to draw the line between the two extremes. Push them to pay but do not push so much that they stop using the product. These payment request schemes might give you ideas for your product:

Desktop Appearance Manager

Software that beautifies the desktop. This software pops up a message maybe once or twice a day that asks for a payment. The message it delivers is humorous and sincere and the unpredictable appearance of the message causes people to want to have it stop interrupting them. The software is fully functional and it is not essential to anyone's business. When they pay, they are mainly paying for the code number that causes the annoying dialog to cease.

Game

A network based multi-user action game. Imagine an annoying dialog that pops up during every 5 games or so that comes up at a critical moment and requires that them read it to figure out how to make it go away. During that time, the other users will most likely kill their character and they will lose the game. Most people will pay to keep that from happening.

Graphical Utility

If the utility does graphical manipulations, you could put an advertisement along the edge of the resulting image. When they pay the advertisement goes away.

Network Utility

For network utilities, you could require that they restart the program after every ten actions, you could randomly hide some results, you could limit them to at most two simultaneous actions, you could timer the software so that after 30 days it starts to become annoying. It depends upon the product.

Word Processor

Limit the size of the document that can be produced, or require that they print one page at a time.

Network Server

Starting after a month of use, every couple of weeks at 2 am pop up a "Please Pay" dialog that stops your server from functioning until they click on it. If your server software is critical to their users, having users complain early in the morning will probably get you a registration fee.

Operating System Extensions without an Interface

For a faceless piece of code, in many cases the only thing that can be done is to put up a payment request on startup. If that is all you can do, that is what you do.

There is a big difference between asking for a payment and convincing someone to pay. When you ask them to pay you want to convince them that it is worth their while to pay. You are creating an advertisement and how you craft it is very important.

Of course your splash screen (the first one seen when launching your product) should ask for a payment if the software has not yet been paid for. But, do not just put your payment request message at startup. People will treat it as a normal part of using your software and they will ignore it. Ask again sometime during the day and hopefully you will remind them while they are trying to make a good impression on someone.

Do not dismiss the payment request message through a simple keyboard button press. Swap the buttons around. Make them read the buttons and select the correct one with their mouse. If they always select the same button to dismiss your payment request, not paying will become a habit. You could also have them do a simple math problem like adding two numbers together to dismiss the dialog. Eventually they will decide that the small fee you are requesting is worth it just to not have to have the payment request interfere with their normal operations. Use TV commercials as your guide. You are the sponsor of this product and making them react to your commercial is part of the game.

Do keep track of user metrics such as; when they first installed the product, how much they have used it, how much time you estimate they have saved or in the case of games, how much time was spent. Give them reasons to pay based upon their usage of the product. Vary your payment request message based upon their usage history.

Some people provide very short trial periods for their software. Few people will install some software and then devote the next two days of their lives to a massive testing of your software. Most people will install it, launch it, and see what it does then not use it for another month or two until the need for your software presents itself to them. Do not use short trial periods. Instead consider counting the actual hours used. If they have been using it actively for 10 hours over a period of a year, chances are they have a pretty good idea what it does and whether they should purchase it or not.

Do not use a specific calendar date to determine when the software should cease to function. We still receive payments for 3 year old software that people have just found on a floppy and are just now trying. If you kill the software on a specific calendar date, you will lose sales. Worse, after that date you will start to receive an increasing number of support questions from people who have not yet paid.

Once they pay, you must acknowledge their payment. Some people develop massively complex password schemes to prevent multiple users from using the same password key. Be careful, you don't want to prevent a paid user from moving their software to their new hard disk, etc. If you create a very complex protection scheme, you will spend lots of time just helping them move software from one disk to another. Paid users will dislike the hassles created by the protection and they will be less likely to recommend your product to their friends.

Extremely secure protection schemes can prevent people from becoming addicted to your product. Do not overprotect your software. Some of the most successful software has the least restrictive protection. In my opinion, you should accept that there will be theft and primarily focus on providing the best product that you can.

The following are some samples of the various protection schemes I have seen on successful software.

None

Clicking on the "I've Paid" checkbox in the preferences window causes the "Please Pay" dialog to cease to appear.

Secret Move

Some software has a field where you can enter the registration code but nothing entered into that field will ever unlock the software. Instead there is some secret move that unlocks the software. For example: click the red shoes three times and then type OZ.

Secret Code: Universal

There might be one secret code that you give to everyone who pays. They all get the same secret code.

Secret Code: Random

The secret code might be randomly constructed where specific characters in the code are derived from the other characters so that your software can determine that the code was probably generated by you. Otherwise the characters are random.

Registration Code: User Data

It is very common to derive the registration code from information provided by the user and then to display that user information in the software so that their information gets passed to anyone to whom they give out their code.

Unlocked Version

When someone pays, they are sent or given instructions on how to download the unlocked version of the software.

Caveats

Do not tie your software to someone's hard drive parameters. People reformat their hard drives, they upgrade to larger disks, sell their machines, etc. If you tie your protection to hard drive parameters, you will do lots of support for paid users every time there are changes to their hard drive.

Do not threaten to erase their hard drive if they are using a known pirated registration code because you will get blamed for the next bad thing to befall their computer. Do not even joke about erasing their hard drive.

Pirates

If your software has any value, its protection scheme will get cracked and registration codes that work will get posted on the internet. Keep track of registration codes that have been posted to the internet and in future revisions, disallow these registration numbers.

Do check for registration code validity in several places in your code and only enable some of these various checks on, for example, odd weeks or even months. If someone publishes a patch for your software, it will work until the next month and then it will cease to work. The cracker will have moved on to other programs and everyone who was using the pirated version of your code will find that it ceases to function.

If you are worried about pirates posting your registration codes to the internet, and you know where such codes get posted, before you release your product, you might wish to post some fake registration codes that cause the program to appear to be unlocked. Why should a pirate crack your software when some other pirate (you) has already done so? After some period of time, the software can then revert back to being locked.

Time to Ship

When you are completely finished with all your documentation and bug fixes and the product is bundled up and ready to upload to the Internet, send it to your beta testers and have them beat on it for a couple of weeks. Repeat this cycle of beta testing and bug fixes until all the beta testers report no problems. Only after they say it is ready to go should you release it to the world.

Pricing

For the software that Kagi handles, US$ 10 seems to be on the low end and US$ 80 seems to be on the high end for single user software. The average seems to be around $18. The best price is the one that brings in the most revenue and choosing that price is always a balance between selling millions of copies at a one dollar each and selling only one copy at a million dollars. Ask your beta testers for their opinion. In the final analysis, your software is only worth what others are willing to pay for it.

A program that does something simple and is not critical to the user should be priced less than a program that is essential to a user's productivity. People will pay more for a unique product with no competition, for a useful product, and for a product that is just way cool to have and enjoy.

A low price is only essential when someone has to buy it before they can try it. If someone can try your product before they buy it, the question they ask themselves is whether it is worth the money to remove the annoyance, not whether the price is too high. For many people the price is not an issue, it is the hassle of paying that delays their payment. Once you set the price, changing it can create problems so give it some thought.

How to do a price increase

It is easy to lower your product price, it is difficult to raise it. The best way to raise your product price is to create a new and improved version of your software that justifies the price increase. Secondly, you should give it a slightly different name, for example you might go from MyProgram to MyProgram Pro or MyProgram Version 2.

For a smooth price increase, you should have three prices, MyProgram at the old price, MyProgram Pro at the new price, and Upgrade to MyProgram Pro at the difference between the two prices.

The registration codes (if any) that you issued for MyProgram should not work by themselves for MyProgram Pro. Have new registration codes for MyProgram Pro. Create two types of MyProgram Pro registration codes, one that can be used by itself and one that requires the earlier MyProgram registration code to be complete. For the people that are upgrading, just give them the upgrade portion of the code.

There are other ways to do price increases but this seems to work pretty well for most people. Vastly improved product justifies the price increase and giving it a slightly different name tends to eliminate the confusion that people might have concerning which price to pay.

Sales Results

You are now at the point in the product cycle where you have a huge advantage over big mega-companies. If your product is not providing the financial success you expect, run experiments to find out why and then try corrections. Perhaps people are not getting exposed to your product and thus they are not becoming addicted. Perhaps they love it but are not paying for it. Perhaps there is better software available, or the price is too high.

Give yourself time to identify whether it is your product or your marketing of it that needs to be revised. Try things and see what works.

Exposure

Part of what you must do is to get people who should want your software to try it. If they cannot use it immediately without reading the manual, people who would otherwise love it will never be really exposed to it - make it usable. If people do not download it, you need to do a better job of reaching your target market and keeping them exposed to your product. Issue revisions and explain in the revision notes that you post on mailing lists and in news groups what problem the revision solves so that others with that specific problem will give it a try.

Keep in mind the adage that "Any exposure is good exposure". Several software authors have indicated that their sales went up drastically after bad software reviews in major magazines. Don't be afraid to get a negative review.

Slow Payments

Perhaps your users are weighing the annoyance of your payment requests with the cost of the program and are deciding that the annoyance is more cost effective. You can lower the cost to below the annoyance level or you can increase the annoyance above the cost. Experiment and see if either works better.

Competition

Your software must be better than your competition by some noticeable way. Find out what your competition cannot do that users want and provide that. This does not mean compete feature by feature, this means find a group of people who are unsatisfied with your competition and make them happy.

Price Too High

I have never heard someone indicate that lowering the price of their product by half doubled their sales. Only lower the price if that is the only objection for people. When they say it is the wrong color and it is too big and it is too expensive, ignore the too expensive part and concentrate on the other complaints.

Write a good product in some area where you have expertise. Before you write it, make sure that lots of people would want to use it. Make it easy for them to try it. Bug them just enough to get them to pay but not so much that they stop using your software. Do not quit your day job.

Kee Nethery operates Kagi, a payment processing service for people who sell products on the internet. This article is composed mostly of expertise contributed by the programmers who produce products sold by Kagi. They and their products are listed on the web site at http://www.kagi.com.