Ask HN: When to release?

I think you should launch as soon as your service provides enough value to someone that they should care. If no one cares, it doesn't provide enough value (for whatever reason). If people do care, then you know your on to something.

If you launch before you provide enough value, no one will care.

If you wait to launch, you are only doing yourself a disservice by delaying or prolonging the feedback cycle. You should be doing the opposite, figuring out how to make your feedback cycle as short as possible.

Worrying about competitors at this stage is dumb. You could only be so lucky as to have an idea good enough that someone would care enough to try to challenge you for it.

One of the advantages you have as a start-up vs. larger corporations is that you CAN launch something before it's "ready". Getting feedback quickly and early is essential to evolving your product.

It's common knowledge that the earlier a bug is found the cheaper it is to fix. Same goes for problems in UI design, etc.

One thing to consider is to what extent the user will be depending upon the quality and comprehensiveness of your specific product. A product used for recreation or convenience may be very partial and/or may fail frequently without causing much disappointment, and users may be happy to have it early. In contrast, my startup made a product that many users considered vital to their professional and business success, that required substantial initial investment of effort, and that users often used under considerable time pressure. Anyone starting to use the product who became wedged by incomplete features would be extremely unhappy. For this product, it was necessary to get it over a fairly high threshold before offering it (apart from a demo or alpha with no expectation that it could be depended upon). Most products aren't in this category, and profit from early release. But even so, for your specific example, I tried Pandora on its release day and was disappointed, and wrote to Tim Westergren to tell him so; he answered within minutes promising future improvements, which should have been impressive enough, but it took me two or three years before I tried Pandora again (I'm now an enthusiastic paying subscriber).

That depends on what you're trying to build. For most startups, getting early users (not a full launch but a limited alpha/beta) is key in developing a good product.

Sure, given more time you could just keep perfecting the product to your standards, but if you don't have a good idea of EXACTLY what you're building, why not do a limited release and work with the feedback that these alpha users give you to improve your product as opposed to waiting for a really long while before you release something that you (not the market) thinks is perfect in every respect, that sounds like a really good way of failing.

Yes, you're going to lose some people who will hate the product and find it useless, maybe they're not your target market. Maybe they are, if they are, listen to the feedback that they give you and hopefully retain them. If not, well, you don't care about them anyway.

3-4 year long dev cycles are generally not a good idea, since user driven development is key in making good products.

You can do it if you're Apple and you have the in-house expertise and market research to know EXACTLY what your users want, but if you're a scrappy startup, you have nothing to lose by launching early, and often and failing fast.

There's no rule of thumb when it comes to launching. Everyone recites the rhetoric of release early and iterate often, but that can lead to releasing a premature product.

Your product only has one reputation, so more important than "when" is "how". You'll want to make sure you have at least a differentiating feature, a marketing plan in place, and a good initial spike of users to even begin to draw worthwhile feedback. Having small sample sizes just leads to noise, which can then lead to even more indecision than you began with.

The best way to think of a launch is not as a switch you flip, but as a reveal that you build up to. The balsamiq guy had a great blog post about prepping for launch: http://www.balsamiq.com/blog/2008/04/18/preparing-for-launch...

It's as close to a video game walkthrough as you'll find.

Is your product good enough to blog/tweet/tell friends about? If so, you're probably ready to launch. If you think it'd get bad reviews, keep working.

Depends on whether what you're building is free or costs money. Each results in different expectations on what you provide at launch.

Common creed I've read around the startup world seems to be "release early, upgrade often", but I've always thought you must have a strong (note: strong doesn't mean many) set of features before launch.

I think it depends a lot on what your service is. I'm working on a startup for hikers (trailbehind.com) and we were live from day one. But most of our traffic comes from searches, and we've gotten more and more traffic from searches as we've gotten better and more popular. We've also had some hard core outdoors fans find us and send us great suggestions and even data. But if we were a service like Pandora, that model wouldn't have worked, since people would have had to remember to come back after a bad experience.

One important factor to consider is scalability. A lot of people like to launch with a relatively immature server that only supports a relatively small # of people in a beta with the idea that they will expand it after that # of people come in. I think this adds an extra risk of someone absorbing your ideas and it's better to get a nice, horizontally scalable server. You don't want to break on slashdot or techcrunch and then have the site go down under load.

I am always for launching as soon as your thing is operational. Real users and critics need to shape your startup and technology, and nothing can replace that.

I like the minimum viable product approach:

http://venturehacks.com/articles/minimum-viable-product