This is something I’ve thought about for a long time and I think I’ve finally come up with a succinct answer: as soon as possible with the minimum set of features that still lets the project accomplish its core goals.

Before we get into this full-steam, sildenafil there are obviously exceptions such as big title video games where the consumer expectation is to be delivered a single piece of completed software that never needs an update. This post is aimed primarily at web-apps but will also apply to most other applications (including indie video games).

Who cares?

This may seem like a very minor issue or a personal preference, web but I really don’t think it is. As a developer or as someone who knows developers, you probably realize that the vast majority of software never gets finished. Furthermore, too much of it is poorly written. When you choose to release a product and how you get there are both major factors in addressing these concerns.

My recommendations

Bullets are fast, lets use them!

• Figure out what makes your product concept compelling to users. If you can write this in one sentence, that would be good. Here’s an example you may recognize: LyricWiki is a free site which is a source where anyone can go to get reliable lyrics for any song, from any artist, without being hammered by invasive ads. Even if you don’t word it as a sentence (which you really should figure out at some point*) for now, just make sure you have the main features: {free, reliable lyrics (wiki-editable), good coverage, no invasive ads}.
• Even if you want your product to have a bunch of tangential-features which you think will make it awesome, make a list of only the features that are mandatory to meet your project’s core goals.
• When you’re writing a feature, write it right. While I think you should cut back on what you implement, my experience has been that you almost never get to go back and really polish features as much as you’d like to after-the-fact. Do it right the first time. Also, if you ever do get the chance to go back you won’t remember the code quite as well as when you’re writing it the first time.
• Release it! As soon as you hit your minimum goals, don’t hesitate… put it live! If you have friendly users asking you for fixes and new features, that will push you to continue. You probably created the project because you wanted to make something that would be used… so people actually using the product and wanting to use it more is one of the best forcing-functions to get you to keep working. It will be an even better motivator if you actually use your product yourself because you will quickly start to yearn for new features or bugfixes.

*: A full sentence like this should guide your decisions as the project grows to keep it from bloating. Also, when people social-bookmark, blog about, or tweet your site they will quite frequently just paste this sentence. Having it as the first and most prominent sentence helps. Also, people are going to ask you “what is your site?” in loud, crowded rooms dozens of times. If your project is successful, you will literally have to describe your project hundreds of times. My current loud-environment elevator-pitch for LyricWiki is: “it’s like Wikipedia for song lyrics… called LyricWiki.” This evolved primarily because apparently people couldn’t hear my enunciation of “LyricWiki” in a loud room unless I had pre-prepped their brains for both lyrics and wikis.