@AndrewChen

Andrew,

Besides the useful comments on this post, can you list your thoughts on how it should be done?

Andrew, we've actually done both for our service at www.loudappeal.com. We basically created a set of communitizing widgets that get auto-injected on a supported blog platform, or a site, and the click through on the widgets takes you to the destination site. The point was to be as distributable and embeddable as possible and add all the meat into the widgets before beefing up the destination site with a set of more destination-site-like services. Our challenge will be to become viral across sites.

It really depends on the nature of your product. A couple of questions that might help in making a decision are

- is your product a network good? Do you need many users for it to be even moderately useful? If that's the case starting your destination site without a major marketing/acquisition push is going to have a tough time in getting traction.

- is your product viral in nature? These days many people think that just releasing something on social networks equals many users flocking to your app/destination. If your product is not naturally viral (or if you don't make it such) launching on social networks doesn't help you much. Just look at growth rate of 99% of applications on Facebook and you will see what I mean :)


- Do you want to establish a relationship with "your users" or are you just after eyeballs. Most applications are social network fail at creating a brand and subsequently a strong relationship with their app users (I really wouldn't call them my users if all I know about them is their Facebook uid).

You need an option for both at once - while the standalone site is the most important part and what we are developing first, the social network apps are really important for bringing users to the site, so can't be left until too much later. We plan to have both available at launch.