del.icio.us was built over several years with only incremental improvements.

Plus, early adopters are tolerant, and if you choose them right, easy to impress. To quote someone else (maybe pg, i can't remember who right now): "It [your first release] doesn't have to do EVERYTHING, it just has to do SOMETHING". sage advice. If have a good relationship with your beta testers, I'd say release every new feature as you code/test it. Feedback is god's gift to startups.

This is, of course, easier to do when you're adding to an existing production application. You can launch a new startup site with one small feature, you need a compelling package of features. Once you're up then this advice is more useful.

I do like the short iterative feature/flow based approach in general though. It really does help keep you motivated, and it gives you something useful to show your users/clients/etc... on a more regular basis, which in turn gets you access to feedback and usage patterns earlier, etc...

I agree it's more relevant once your up and running. But you should also follow it when you're launching.

Anyone remember what facebook's wall was when it launched?? Yep, just a textbox! And facebook had no photo albums or anything like that, just profiles and friends. It was pretty much a couple mySQL tables with some php displaying the data. And people still flocked to it.

I think that is a good call, when I get tired of just making micro improvements across our project or fixing bugs. It is great to really gett o sink your teeth into a new exciting one of project that gets you deeply involved again even if just for awhile.