Treat it as finished

It's finished when you have a disaster and recovery plan. If you don't have everything being backed up in some way, you're just running programs and waiting for them to die, or for accidental mistakes to be made and data to be lost.<p>At the beginning, this can be simple as a 3 or 4 line script that compresses all your files, dumps the database, and copies it offsite, which you run on a daily/hourly basis.

Joel, great post<p>I think we are all a little afraid of saying "it's finished" because we have no comeback when someone says "it sucks". I guess its that fear of rejection, whereas if we say its unfinished we can always claim the "yup we know, and the next release will be better".<p>Surely this is why the fad of slapping a Beta sign all over the products started, just to let people know that "it has some bugs an we know about them" What we really wanted to say was "It has some bugs, which we have no clue about, and we want you to help us discover them" :-)<p>As for the blogs, I agree, way too many , and any review is a good review.<p>Iqbal

It's about creating something simple but decent for V0.1 - then letting your customer's metrics guide you on how to improve it

Great article Joel. It is hard to get into that way of thinking when you're being a perfectionist over things, but you're right. Getting validation early and often will drive your featureset and refinements going forward.

Good post Joel. It's really hard to have that mindset, but I think you're right. Promote and gain traction, then refine.

Great post. Don't just ship early, promote early.