Five years ago the two of us that started CoderTools thought that we would be in a different place to where we find ourselves today. We had hoped that TotalEdit and our other endeavours would be successful to the point where we could quit the day job and work full-time on the things that we loved. We jumped feet first into what experience has taught us is a very complicated business, that of the Micro-ISV.
Like most people we naively thought creating the product was the most complicated part and did not give enough credence to things like PR, marketing and sales. We knew that they were important but in the words of Dilbert "What I do not understand, must be easy" became our mantra as we gravitated toward the one thing that motivated us, and that was to write good software. The lack of money and understanding of the other roles meant that they were not given the attention that they really needed.
The last five years have been very interesting and expensive especially as CoderTools has been run at a loss. Would we do it all over again? Absolutely but with a number of modifications, which I would like to share to anyone considering on embarking on a similar project.
Before you do anything understand that you are at the start of a very long journey, which will require a number of different skills. This is just something to be aware of as I have met and known quite a few folks that fell in love with the idea of running their own business but didn't appreciate just how hard it is to be your own boss.
Next research your idea to see if there is a market for the product(s) that you will develop. The mistake we made with TotalEdit was that we underestimated the strength of a brand especially with regard to our competitors and the number of downloads they receive each day. We reviewed web sites like CNET's download.com and allowed the reported download figures to influence our decision making. Once you have your idea research as many paths as possible to verify that there is a market for it. Use the Internet, news papers, ask your friends and family or even survey people in the street, anything that will give you feedback.
You will need a business plan, which you should be treated as a living document. That is, continue to review it and make updates as you see fit. Now that you have your idea, write into your plan the steps that you intend to take to achieve it? This process will cost money so what will you spend and when? Will you need to hire anyone? Pay yourself a salary? Outsource any work? And what benchmarks will you use to ensure that everything is going to plan? Most important though and once you have started to sell your product what predictions are you going to put in place that reflect your expected sales? Be cautious with the last piece though as it is all too easy to overestimate and before you know it the spreadsheet reports a lottery winning profit at the end of each month.
Feedback is king. When we first started writing TotalEdit we essentially wrote it for ourselves and our needs, which were not necessarily the same as our customers. Feedback allows you to write software that meets the needs of your customers, which will save you a lot of man-hours in development and testing and keep you from writing functionality that is not required. It is worth noting and something we learnt after we made TotalEdit free is that generally people do not provide feedback on products that cost money. Instead try to find some people who will work with you whilst you develop the product. This isn't as hard as it sounds. For example, let's say that you plan to create a subscription web site that offers a time management service. In this scenario I would pick up the yellow pages and call small to medium sized companies in the local area and identify who would be willing to work on such a project. I would offer free access to the web site for a given length of time in exchange for ongoing feedback and ideas to enhance the product.
The last thing that I will say for now is "little and often". Some people would call this Agile development and for the Micro-ISV this means that you should do time-based releases rather than features ones. That is, create a schedule, which could be a plan to deploy an update once per month. Then create a plan, which will enable you to write the software update, deploy it, get feedback within that timeframe. Give yourself time to analyze feedback before repeating the cycle.