Last month during the Facebook privacy backlash, Jason Fried from 37Signals wrote a great post about Diaspora, the “open source” Facebook that raised $200,000 on Kickstarter before even beginning their project. They received publicity from mainstream media outlets like the NY Times and the fund raising took off. His argument, one that I agree with, is that Diaspora is taking the wrong approach:
Diaspora has all the wrong things at the wrong time. Competition that kills isn’t pre-announced — it catches an unsuspecting incumbent by surprise.
In particular, I found one of his points to hit home:
The spotlight is on too early
You want attention after you’re good, not before. Obscurity is your friend when you’re just starting — especially when you don’t even have a product yet. You don’t need the pressure of outside opinion or the press breathing down your neck before you have anything to show. Millions of eyes — including your competition — watching you every step of the way doesn’t help. All this attention is a distraction. Ship, then seek the spotlight.
I’m going to go out on a limb and say that every single piece of software – web or otherwise – that has ever been released in the history of computers has been buggy at first. We’ve had a pretty disastrous start with LockerPulse from a product standpoint. We’ve had every potential hardware and software problem that I could have imagined. The site has been unstable as hell.
Some people might look at this as a bad thing, however, because we did a small “beta” launch, we were able to get real users on the site, get real feedback, observe what worked and what didn’t, and then begin to fix things. You’d think that because we’ve launched a lot of websites over the years that we wouldn’t need time for this stuff and that we could just go full blast with the site from day 1. It just doesn’t work that way, especially with software almost 100% built in-house that has never been used in a live environment before. It has been a little worse than I had expected, but then again I wrote this just before launch:
We’re going to do a “public beta that we’re not calling a beta” for a few months and then go from there. What does that mean? We’re going to be giving out free lifetime premium accounts to a bunch of people we know (friends, their friends, family, people we know in the web business and sports business), we’re going to be testing a micro social media campaign to gauge it’s effectiveness (we think Twitter is maybe our best marketing opportunity), we’re going to be soliciting feedback and collecting data, and then we’re going to go from there. We have a laundry list of things that we want to do, but none of that matters if the first 50 people that try it think it sucks. This is an app on a level that I haven’t built before, so it’s important to make sure we didn’t royally screw anything up before going too crazy. Right now it looks like we’ll be adding 50k – 75k stories per month to our database. There’s a lot that goes into making that work efficiently.
Now, some 40 days later, we’ve worked out some serious coding issues, made some changes to appease some of the major content providers, completed a UI redesign, and moved to a much better server*. We’re getting close to the point where we have the kinks worked out and we’ll be confident spending some time and money to market the site. Imagine spending thousands of dollars for some big huge launch and then realizing that your server couldn’t handle the site or that half of your users couldn’t use your interface?
“Obscurity is your friend when you’re just starting.” I love that quote from Jason. This past month has been tough on me, but it would have been much worse if all of the problems were exacerbated by gobs of traffic. If the site is slow/down, I might get an email or two. If I got a few hundred it would be a different story. Then you’re playing disaster control with your customers AND trying to fix a bug.
Big huge launches are sexy, but they aren’t very practical, especially for a small bootstrapped software project. Slow and steady wins the race.
*Originally I had picked out a VPS to start development. I thought we could launch and be OK in that setup for a little while, but it became evident that we needed more power and even more flexibility should we grow the site quickly (no one wants to fear being too good at marketing, it’s hard enough as it is). Our hosting provider, LiquidWeb, who we’ve been with for years and I’m very happy with (no downtime…ever), worked with us to transition the site to their new cloud product, Storm. This gives us the ability to add RAM or a CPU or even a load balancer with a click of a button, something I think is necessary for a site like this. I had originally considered Rackspace Cloud and Amazon EC2, but Rackspace had too many downtime horror stories (see TechCrunch), and Amazon didn’t have a level of support I was comfortable with. Cloud servers are the way to go for web apps now a days, so I’m happy that LW is finally offering an option that works for us.