How to Sell Successfully in the Shareware Industry

A practical guide to making your first million. Or billion.

Many people have become an overnight success with a single shareware product. Part of it is to have a good idea to start with - but that's only a small part. The most important part is planning. Read on.

Find Your Killer App

Whatever you want to sell, make sure there's interest for it. This is more a marketing issue than a programming issue. If necessary, talk to that uncle of yours in IBM or fast food. He might have some good ideas. When you have your killer app idea, move on.

Press Releases and More Press Releases

Find someone who knows how to write a press release. Have him write one for your killer app. Fill the release with lots of mumbo jumbo about design reviews, phases of this and phases of that, 'the early alpha stage', and so on. Make it sound like a major multinational project. That's always impressive. Give approximate dates like 'early spring 2007' so it looks like you've planned things well.

Release Early, Release Often

A great many software developers make the mistake of waiting too long to release their products. They're burdened by things like ethics and professional pride. THIS IS COUNTERPRODUCTIVE. You must release early and release often.

A very important rule is to NEVER worry about bugs. Bugs are your friends! If you don't realise this now, you'll accept it as an inalienable truth by the time you've finished this article. BUGS ARE YOUR FRIENDS. So don't worry about them. And don't spend time trying to eradicate them. Leave them and instead work on FEATURES.

Your goal for your first release is to have a basic feature set in place. This feature set must adequately showcase your killer app and make it obvious why your killer app is a killer app. Just don't go overboard here - get the basic feature set implemented and put everything else in the queue for later. (See below.)

Fictionalise Your Alpha Testers

Make a press release stating that your product is in alpha and has gone to a select group of testers. Indicate strongly that this alpha version is not available to the public at large. This just whets the appetite of your future buying public.

Note that you do not actually have a group of alpha testers or even an alpha version for that matter - you simply make a press release to that effect. At this stage you might not have a single line of code, and that's totally cool.

Cultivate Your Beta Testers

Once you have a rudimentary version - full of bugs of course - ready to go out, make a press release announcing your beta program. Everyone gets to download a copy for free. Don't make people jump through hoops to get a copy, but make the process full of pomp and circumstance. Your 'beta testers' are worthless as beta testers as everyone knows, but they're priceless as a marketing tool. They spread the word - and they do this because they're so proud they've become a part of a 'beta testing program'.

Cultivate these people. Answer all their letters with courteous replies but give no information away. Thank them for their input etc. No more. Archive these letters as they will come in handy later.

The Bumpy Road to 1.0

1.0 is your goal: that's when you start making money. But don't jump there too fast. You can take months or years if you want. Remember what the payoff is going to be. Start with 0.1 and then complicate things with version numbers like 0.1b and so forth. Delay the move to 0.2 as long as you can - and the same goes for 0.3 and so forth. Take your time!

Open the Forum

Get a forum up right away. Here people can discuss your killer app. Your killer app might (should) look like shit at this point - but that's the whole point: people have to have something to discuss. Actually a forum is a better option than accepting bug reports and suggestions for new features.

Through the Window

Most of the time the feature suggestions people come with are really stupid. Don't tell people they are stupid - don't tell them anything. A good basic rule to deal with all the feature suggestions you will get is to send a quick thank you reply and then just destroy the message. In the forum you should have a dedicated thread for feature suggestions so you can ignore it all the better. Let this stuff just go straight out the window. And into the trash where it belongs.

The Box That Isn't

No one wants to sell shrink wrap products, but that doesn't mean your product shouldn't look like one. Have someone design a shrink wrap picture of your product and put it online. People respond more favourably to a box.

The User Manual

Have someone construct an elaborate overly simplified and incredibly wordy user manual in a format like PDF. Sell this manual separately for an additional cost. A low end figure here would be $25. (Yes, for a single PDF file.)

Your First Release

Don't wait for a bug-free product to announce 1.0. Ideally your product should work only some of the time and definitely not all of the time. It's to give a glimpse of the great things to come - but should definitely not have any of these good things so early in the game. Perhaps version 2.0 or even 3.0.

As you climb towards 1.0, start putting time controls in your product. No one is going to want to keep the really early releases as they're so shitty, but as you do improve some people will consider keeping a free version instead of paying for it. So make sure your product runs out and does so gloriously.

Now is the time to start publishing your coming price. Also, you should make a new press release giving the exact date for this 1.0 release. Remember that it is not important to have a good version for 1.0 - there are no deadlines to meet - but you must brace your public for finally whipping out their credit cards for your sake.

Don't even consider giving your beta testers a discount. If they've followed you this long they'll consider it a privilege to pay full price. Help them with this. And whatever price you decide on, add 10% right off the bat. If the price is too low, they'll get suspicious. For maximum effect and maximum profit, your price should be just shy of outrageous.

Bug Fixes Mean Millions

Once your product is out there and making you a trickle of money, it's time to go into 'response mode'. It's now you start listening to your customers and archiving everything they point out. What you want to do is come with a new version as soon as possible to make even more money.

Remember that the best customer is a repeat customer - the customer who's already bought your product once. You're going to get him again and again because you're going to come out with new versions faster than a hummingbird flaps its wings - but to do this you need LONG LISTS OF BUG FIXES EACH TIME.

This is why bugs are your friends: as your product reaches market and people notice what's wrong with it, they will write to you (or to your forum) and tell you. You track down every one of these bugs and list the fixes meticulously.

Then when it's time for a new release (two or three months tops) you make a long list which you publish. Use dates or index numbers or both.

2007-01-01 Fixed a bug which caused the program to crash without warning.
2007-01-02 Finally (yes we promise) fixed a bug which prevented the program from running at all.

And so forth. This is why bugs are so important: without bugs you have no reason, no justification for coming out with a new version and getting paid again.

Your new version will be available to current customers at a discount - 25% is a good figure. 'Current customers' means only those using your previous version: if someone is using a much older version, then they get no discount. Figure this way: if they're using a much older version, that version's going to be crappy compared with your new one, so they'll be more or less forced to upgrade anyway. So make them pay.

More Features Means More Bugs

It's very important you never run out of bugs to fix: again, the key is that if you ever run out of bugs to fix, you'll have no way to introduce new versions and no way to force people to upgrade.

But as you fix bugs, you might - in theory at least - get to a critical point where your program is working well enough that it doesn't really need too many more fixes to run and be adequate for its intended original purpose. YOU MUST NEVER REACH THIS POINT.

Remember that you were not to overburden your project in its initial phases with too many features - you put these features in the queue. It is now time to take them out and begin implementing them.

As you implement new features, you will introduce new bugs. If you're lucky, it'll be a lot of bugs. Which begins the cycle all over again.

Form Over Function

For all shareware users and especially for Macintosh users it's 'form over function'. 'Form over function' is an important concept which means that a program doesn't have to do a good job to be successful, it only has to look good.

Make sure you have lots of colourful images and toolbar buttons and so forth. Lots of them. Don't worry about function here: that's the whole idea - it's 'form over function'. It's what it looks like, not what it does.

Ease of Use

Ease of use is another important concept in the design of your product. It is very important to understand the world of difference between productivity and ease of use. No one expects your product to be productive, despite the close relationship of those words, but they want it to be easy to use.

Your customers will have little to compare with and won't be equipped to measure productivity, so make sure it's easy for them to use. You should above all avoid any work steps that involve typing or multiple sub-steps. Everything should be click and drag. You should have gobs of click and drag possibilities in your product. You should have them everywhere. And don't worry about user errors. (See below.)

It's Their Fault

When you put too much functionality in a shareware product, it's easy for things to get out of hand. Lots of things will go wrong. The product will be prone to error. DON'T WORRY! Most users have no clue what's a design or programming error anyway and most of the time won't even notice the error until it's too late - by which time they'll assume they and not you made a mistake.

It's possible to write software that protects data and the user from mechanical accidental errors BUT IT'S BAD BUSINESS: it drains your resources when they're needed for much more important things.

The Tinkerbox

Shareware users will never understand beans but they still love lots of configuration possibilities. In professional software (as opposed to shareware) these settings are normally dealt with in an intuitive way. THIS IS WRONG. Make everything overly obvious in super whiz-bang configuration dialogs. Spare no expense in making everything - literally EVERYTHING - configurable.

Stroke Their Egos

Above all, stroke the egos of your customers in the way you make them use your product. Once upon a time there were only a few people anywhere using computers, people like Charles Babbage and Alan Turing. YOU ARE NOT WRITING SHAREWARE FOR ALAN TURING.

After a while there were more people using computers, people in academia with science degrees who dabbled both in using computers and in programming computers. YOU ARE NOT WRITING SHAREWARE FOR THESE PEOPLE EITHER.

Even later on there were ordinary people with little or no education who nevertheless had a knack for tinkering with computers and who could enjoy the abstract pleasure of working with weird things like terminal consoles and command lines. FOR HEAVEN SAKES YOU ARE NOT WRITING SHAREWARE FOR THESE PEOPLE EITHER.

As the Internet broke loose and the 'web revolution' came into full swing and everyone wanted to get connected to the Internet but few knew why - that's when the great demographic of today came into play. YOU ARE WRITING SHAREWARE FOR THESE PEOPLE - NO ONE ELSE.

These people often have an innate fear of things they don't understand. (Consequently they have a great many fears.) They don't understand computers and they never will - BUT IF YOUR SHAREWARE PRODUCT MAKES THEM FEEL THAT THEY DO UNDERSTAND SOMETHING, THAT THEY'RE FINALLY GOOD AT SOMETHING, YOU'LL HAVE THEM IN THE PALM OF YOUR HAND AND HAVE THEIR MONEY IN YOUR BANK ACCOUNT.

Make the simplest operations in your product seem 'blazing'. Make your customers feel as if they're inventing interstellar travel all by themselves. STROKE THEIR EGOS.

'Hey I just backed up my entire hard drive, tested Newton's fourteenth law of gravity, AND I wiped all my disk free space, AND I reconfigured my firewall - and all I had to do was click this here button right here! Am I great - or what!'

'Wow! Yeah! But what are all those other buttons for? Why such a big window and all those doodads if all you do is click one button?'

'It's called form over function. You're not a computer user, are you?'

'No I'm not - but I'm planning to learn!'

'I'll be glad to help you and show you the ropes.'

'Does that program come with a user manual?'

'No, it's extra - but it's well worth it! And they're coming out with a new version next month!'

'Awesome!'