Sell First Programming

Imagine that you are a shareware author. You just read about FakeIt. And you decide that you want to apply fake-it to bootstrap your tiny shareware business. Instead of bootstrapping your program you want to bootstrap your business.

Here is how you could start. Before writing a single line of code you write an ad for the product. The ad will help you see from the customer's point of view. It will help you define the product and decide which features you need and which you don't.

At this point you might be tempted to crank out some code. Hold it right there. Not so fast. First create a website about your product. Announce that the product is going to be released in 2 months. Ask people who are interested in receiving updates about it to contact you.

The response rate will let you know if you product is a dud or if people might be interested in it.

If there is some interest then you can develop the program and sell it to the people who contacted you. If there is no interest then try again with a completely different ad.

The advantage of this approach is that you can experiment cheaply with ideas and explore whether there is a demand for it or not.

Some interesting comments below. I am interested in ideas of how to probe the market before investing in implementing a program. The above is a simple market research strategy.

This sounds a lot like VaporWare, especially if you then don't write the program...

Also sounds like the approach of some startups during the dot com boom, drove a lot of people into DeathMarch projects when it turns out the initial estimate of how long it will take is off by a long shot.

The top of this page seems misleading. When I clicked into this page, I was expecting a tie-in to XP, with its onsite customer. XP makes sense in that it does a require a buyer before writing any code. The customer gets to define the functionality, then you write it. The approach described on this page might backfire if a customer is misled into thinking a product exists when it doesn't.

For shrinkwrap and shareware products there is no real customer. So perhaps this approach can work as a way of getting feedback on what kinds of products a customer would like to buy. In all cases care must be taken to not mislead the customer.

This can't really be considered "shareware" in any sense. That term implies that people have the product and are sharing it with others. This idea probably wouldn't work in the shareware market: shareware consumers don't pay for something they haven't been able to try, no individual shareware consumer is going to be willing to foot the bill to develop the entire product, and many will be turned off by the misleading nature of creating buzz for a non-existent product. A combination of shareware and Vaporware will probably not generate much profit.

Maybe a reasonable halfway measure would be to create a beta/demo first. That would give the shareware audience something to judge, and give you a better idea about whether anyone is interested in buying the complete version.

ShareWare, OpenSource, or FreeSoftware authors (pick your term, they are similar but not identical) typically, nigh universally, do not write programs to sell, they write them to solve some problem they themselves are having, and as there are often people who have a similar problem, it then becomes something others will want and, perhaps, even contribute to. As an aside, perhaps the whole concept of ShareWare, meaning "download now, buy if you like it", as differentiated from ShrinkWrapped is a bit dated, because nowadays very nearly any software can be downloaded in trial version over the web.

I make a big distinction between writing an advertisement, and posting that advertisement to the Internet (or other publishing media).

Writing an advertisement is good. It helps you see things from the customer's point of view. As long as you keep it to yourself, it seems like a good way to help brainstorm to discover what we really want the software to do. This seems related to ExampleFirstProgramming, TestFirstDesign, TestingFirst, and especially WriteTheUserManualFirst.

As long as you keep it agile, and feel free to update the advertisement (rather than thinking of it as a requirement SetInStone) as you find better ways to do things.

Posting the advertisement in public, to imply that it already exists -- that seems fraudulent.

On the other hand, posting the advertisement, and putting lots of clear disclaimers that the software still hasn't been written yet, may never be written, and even if it does, will have only vaguely resemble the screenshots in the advertisement -- that's the whole point of SourceForge, isn't it ? Maybe that's not so bad.

Contributors: AsimJalis, DavidCary et al.