The story of a project, recorded mostly for my own benefit.
FlyByChat, part 1
"FlyByChat" was conceived as a better Chatroulette. Chatroulette was successful at the time. I thought that since the creator of it wasn't interested in pursuing it seriously, someone else would be stepping in to fill that space. My idea was to use a few "higher order bits" about participants — such as location, gender, interests, college — to make better matches. For market validation, I looked to ChatRoulette (and Omegle), dating sites, and the "bored but social" impulse in general. After launch, people stuck around for about a day.
What I did well: There was one pleasant and productive week when I rented a cabin to work out of: ignoring distractions is good; not have any to ignore is better. I should try that again. Also, launched without much ego fear.
What I did poorly (business): Failed to comprehend the magnitude of the chicken-and-egg problem. Failed to consider how much harder it is to solve for real-time matchmaking. I knew it was a big problem — and I felt like I'd have just one serious chance to achieve liftoff — but it's even bigger than I knew. Without a built-in distribution channel, a site like this is unlikely to succeed no matter how well it's made.
What I did poorly (personal): The deeper problem is that I wasn't working on something that I was passionate about. I thought the site was a good idea, but it wasn't something I imagined myself wanting to use very often. This is a mistake that's hard to iterate out of, and it persisted through the versions of the project below.
What I did poorly (engineering): My biggest mistake was trying to reinvent the wheel on the chat protocol. I looked at existing chat solutions, but only closely enough to decide that they wouldn't work for my use case. It's worth taking a lot of time evaluating existing solutions before deciding to reimplement anything, but especially key infrastructure. Part of this failure was probably me trying to justify my developer impulse toward NIH. Not only did I reimplement chat, but I cycled through several different technologies in doing so, finding none of them perfect (as none of them are).
Things I learned: The upside of the engineering mistake is that I learned a lot of technologies in the process: Tornado, Twisted, Node.js, and AMQP. This is in addition to the other components of the stack I picked up: EC2, nginx, Postgres, Fabric, and Google Closure.
I also learned that even if I launched a bad idea, my friends would really try to help make it work. Nice to know.
FlyByChat, part 2
After the above, I decided that chatrooms, as opposed to one-on-one chat, were the way to go. I don't remember all of my reasoning for this. One part of it was that nothing had come along yet to replace AOL chatrooms. (There were other people expressing this sentiment at the time, which made me worry about competition.) Another motivation was that chatrooms have less of the chicken-and-egg problem than one-on-one matching.
FlyByChat became a site where you could log in with your Facebook or Twitter identity and join rooms based on your interests. People stuck around for about two days on this one — an improvement.
What I did well: The smartest thing I did here was switch to an existing chat server (ejabberd) and client (Strophe.js). So much code was deleted that day. It was immediately clear that this was the right thing to have done from the beginning.
What I did poorly: Still trying to address too broad of a market. No distribution channel.
Things I learned: I got to talk to Joshua Schachter. He pointed out that features involving a transaction between users could be made more or less timing-sensitive. With FlyByChat, for example, users needed to stay on the side while they were waiting to be matched. This is bad, because the window of success is small. There are a few different ways I could have applied this to the original match-up concept. Alternatively, Convore applied this when they made chatrooms act more like forums.
I decided to do one last experiment that wouldn't take too long. It was based on another good piece of advice (from a Paul Buchheit talk): it's far better to make a few users really happy than a lot of users only kind of happy.
My idea was that the existing code wouldn't be hard to modify to be based around Reddit.com. Reddit users would be a smaller but more engaged audience. They would sign in with their Reddit identity; chatrooms would correspond to subreddits, with various room metadata being synced automatically (like moderators).
I had just started on this third iteration when I quit, putting the project on hold, to join a completely unrelated startup. This occurrence is a risk when you try to work on something you're not inherently passionate about.
This past month, well over a year since I stopped working on it, I decided to finish the project. Leaving it "98% done" had been weighing on me. It felt wrong to leave Seddit almost done, and to not follow through on something I'd put so much work into over the various iterations.
I spent a couple weeks fixing it up and launched. A decent crowd stuck around for about four days. Not bad! A few subreddits have officially adopted it. I think that with continued effort, it could be made to have a sizable, steady population of users. Ways to grow from there would naturally appear. But ultimately I'm not interested. (If you are, it's open source.) My motivation in launching it was mostly to give it a chance at life, so I could get rid of it with a clean conscience and focus on other projects.
What I did well: Focused on a small community. This made potential users care more, and gave me a natural marketing channel. So of course, marketing went much better. I talked to users, messaged subreddit moderators, and submitted links, which got me some good feedback and initial traction.
What I did poorly: First, I underestimated time to relaunch. The "2%" that was left was supposed to take about three days; it ended up taking closer to three weeks. Can a developer ever learn? Second, I thought I could "just launch it and see". There is no such thing. Launching gives you some information — much more than not launching — but it can never tell you the whole story. If my goal was to get the project off my mind, I should have just open-sourced it to begin with instead of spending time on a launch I wasn't going to commit to.
Things I learned: Though this is hard to quantify, I feel that I've developed better intuition around social sites, marketing, and a few other dimensions that are more broadly applicable.
Regarding chat in particular, my belief is that chatrooms have seen their peak, and it was over a decade ago. Nothing has replaced AOL chatrooms because chatrooms are boring compared to all the web has to offer now. They no longer suffice as a destination. Their role in popular services, if there is one, will be as a complement to something bigger.
For their help along the way, shout outs to: Nick Doty for help with branding, Louis Morton and Chris Yap for help with design, Aaron Swartz for lending me the seddit.com domain, and Alex Clemesha for help with code.