The benefits I get releasing the autoresponder

The history behind the Autoresponder.

In 2003 I was working in my home-office in a small town in Brazil while trying to get a college physics degree. To pay my bills I was basically building websites in PHP after I left the Perl world. I was part of the staff for a project designed and managed by a grumpy old man in New York. God, I should have sent him a copy of Peopleware (Peopleware: Productive Projects and Teams (Second Edition)). One day he subscribed for an autoresponder service. It was not cheap and the service was not good at all. I thought I could code the same features and add the others we needed in no more than 2 days. I did it in a weekend and started to share it for free. Back then I had no idea what FSF or OSI were. I started the professional version a while later since it was taking crucial time out of my day night to give support and add new features.
Since the release of the first version I receive emails daily from people reporting bugs, asking for new features, giving suggestions or simply wanting to say hello. Well, although it might not help me to sell more copies, I must be sincere about my efforts into this project. Time to work on it is scarce. I switch between my regular job (there are always new projects at a startup) and research mode at night.

Releasing is not easy. I suffered from it and some symptoms I believe are shared amongst a lot of developers. One is frustration. You know you can do better but time is against you. Another problem is loss of focus. I learned how to manage and maintain this project (more on this some other day) in the hard way. I made all the common naive decisions like trying to rewrite it from scratch or adding a new feature to make a new sale.

Not everything wrong though. I’m still working on it, right?

One major key: Releasing.

It taught me a few lessons.

The first version was small and built to do only one task. It solved one problem of mine but it also worked for a few more users.

The main benefit: Feedback.

I not only read and pay attention to all the emails people send me, but also take note of each one. There are two possibilities here.

1. add a ticket to the bugtracking as a feature to be built or a bug to be fixed.

2. take notes in my to-do log for random idead.

After a few tickets and paragraphs I started to notice patterns and features people wanted most. This way I avoid writing fancy features and make better use of my time writing features that people actually want.

The downside of this approach is, unfortunaltely, the elimination of these “fancy features”. One of these features could turn out to be innovative and a killer feature for the app. Right now, I think this is not a concern. I have all  these crazy ideas being developed and written down in my notes. Today these features are expensive for me to code. Meanwhile I have fun building a more mature version of the autoresponder.