A Look Back at Launch – Good, Bad, and Ugly

The launch of my new sports trivia website, Roster Brain, was simultaneously a great success and a huge collection of errors. It has now been a week since the site went live, so it seems like a great time for reflection before I move on.

Let’s start with the successes!

  • The site launched and the world did not entirely collapse.
  • The “soft launch” brought in nearly 20,000 pageviews in the first 24 hours of the site being live.
  • I got awesome feedback from coworkers, friends, and random strangers.
  • Users seemed to flawlessly understand the functionality and calls to action on the site.
  • The site actually made some money.
  • The site must have worked well on mobile devices, because pages per visitor on all platforms was equally awesome.
  • There has been some continued traffic even though my launch links have dropped out of site.

Despite all of these great things, my favorite stat is not listed above…it’s the awesome percentage of type-in traffic. Direct traffic on an unknown site either means people have remembered their previous visit and come back later or that people are sharing the website with others. Both of these are great indicators that the site is well liked and actually a decent idea.

An odd side note: I received more pageviews in the first 24 hours of this launch than I did in my months of SEO work during my self employment stint. A lot of this has to do with the inherent high action rate of users clicking through a quiz, but it’s still hilarious to consider.

Now…the negatives:

  • The site launched broken.
    For whatever reason, the URL rewriting I had worked into web2py took a huge crap when I imported the launch version onto my production host, despite testing in two other environments. Luckily I was able to resolve this by stripping the rewriting in a timely manner. See lesson 2 below.
  • The site stayed (partially) broken.
    I had users report other broken functionality later in the day, which I wasn’t able to resolve until the night of launch. Luckily it only had to do with the roster portion of the site instead of the main quizzing functionality. See lesson 3 below.
  • Search engine spiders could only index 4 pages of the site.
    Until nearly a week later when I wondered why the site wasn’t getting crawled deeper, spiders were stuck on a few basic pages. I tested without javascript on a previous version, but not the launch version…and it broke somewhere in between. Also a part of lesson 3 below.
  • Users didn’t share on social media.
    I had high hopes that when users completed quizzes, they would share their scores on Facebook and Twitter using the buttons I provided, creating a minor traffic draw. Outside of a few friends, this did not happen once. See lesson 4.

Lessons learned:

1. If you launch a product as a side business/project, take the day off of work.

Despite having my morning launch plan laid out in a flawless step by step manner, I was a little late for work. I had to clean up some of the functionality bugs with launch or everyone I had just emailed, spammed, or otherwise gotten the attention of would have arrived at a crippled web experience.

During work, I was ridiculously distracted watching the visitor counts and interactions on my real time analytics (I’m using Piwik and it’s awesome). I know my coworkers could see my enthusiasm, but if I had anything critical happening at work on launch day, it would have affected my performance.

2. Always test in an exact copy of the production environment.

Neither I, nor the gurus on the web2py google group, could explain why my rewriting was failing (mostly because I don’t think it was). The production environment acted different than my local machine and my live testing server, despite having the same web2py version and the exact same code. If I would have testing on my production server (in a non-public directory), I would have seen the problem in a much more pleasant timeline. This brings me to #3…

3. Freeze development 2 weeks before launch.

Especially if you’re a one man show…you need time to test absolutely everything that you’re going to launch. I tested in several places and even had other eyes on the private beta, but some late changes/additions broke some significant portions of the site at launch. If I had frozen development except for bug fixes, I wouldn’t have created some of the launch problems.

Also, this will give you time to focus on other aspects of the site. Make sure you’re launch plan is in place, notify some key people, and create some minor launch hype.

4. Social media promotion pretty much sucks.

I expected a lot more out of Facebook and Twitter. Even with some supportive coworkers sharing my site on Facebook, traffic was pretty dismal. As a one man show with a one trick pony, I don’t have a lot to say on these platforms to create any type of draw without sounding like a desperate beggar. Without people sharing themselves, these promotions went nowhere fast.

In addition, shouting into the blackness of a Facebook or Twitter timeline doesn’t seem to get many eyes on it. I don’t have that many followers to start with, but my posts must have been either completely uninteresting or pushed below the fold pretty quickly. Unfortunately this means that marketing the site is going to be 100% manual, something I’m not very excited about.

Maybe all blog posts should have a summary

The site got a lot more traffic than I anticipated, but dropped off after about a day and a half. Users seemed to understand and like the idea of the site, but did not share using the social media buttons I provided. I got a lot of awesome feedback and suggestions that I’ve put into a plan for a phase 2. There were a lot of bugs at launch, but everything is working now!

1 comment

  1. Way to go Brad! Congrats on your efforts. Hope you continue to do well and remember that “success is the journey, not the end.”