Post-Launch Prep II

After launching BizeeBee I realized that my initial post on what to do after you launch your startup wasn’t enough to cover all the work that the BizeeBee team has done after launching and thought I’d share some of our efforts.  We launched BizeeBee about three weeks ago with a few yoga studios across the nation.  The on-boarding process was pretty smooth, but once we had customers up and running I had an epiphany:  we have paying customers who depend on us for their livelihood, and we are a reflection of their business.  The team’s entire perspective about how we were managing our development process changed!  Here are the key things we added to our process:

1. Backup and Restore

We were responsible for the reliability of our users’ data.  They need this data to understand the health of their business and convey it to their customers.  If something happens we need to be able to retrieve their data and most importantly restore it!  So we started doing backups, initially daily, but will move to hourly.

2. Testing

We could no longer just deploy to production anytime we wanted because our users use our product daily and hourly to run their business.  While continuous deployment is pretty seamless, I was more afraid of introducing a bug during someone’s working hours, so I wanted plenty of time to test and do a hotfix if necessary.  If testing hasn’t been a priority in the alpha or beta, it should become an imperative once you’ve launched.

Even if you don’t have time to setup a full regression suite, you can take a cue from our development process:  we have all our flows documented, and run through all of them manually every night, even if the feature hasn’t been touched in months.  We also test across the three major browsers: Chrome, Safari, and Firefox.  The last thing I want to break is something simple like password recovery or deal with browser interoperability issues.  We’re working on creating an automated suite that will run daily to ensure code quality.

3. Branches

I initially disliked GitHub but now I love it!  It has made branching and merging a breeze because unlike SVN the cost of checking out and switching between branches is very low.  It doesn’t suffer from the same large data footprint that SVN does.  We created 4 categories of branches: master (current development branch), features (one off apps like internal tools), releases, and hotfixes, and also setup a policy of what could be checked into each branch.  For example, once a release branch has been created we can no longer check in new features only bug fixes.  Instituting these kinds of policies minimizes risk of introducing a bug after a release, and people have a good understanding of the ongoing changes in each released version.

4. Track Customer Support Issues

I created an admin tool that lets me login daily to see our user growth count and feature usage.  This also lets myself and my team troubleshoot any issues that customers might be facing.  It has read-only access to their data and the authorization is limited.  If you find yourself constantly querying logs and databases, and have teammates who don’t know SQL or how to query logs then creating a tool that reflects the data empowers them.  And resolving customer support issues as quickly as possible is critical to the quality of your startup!

These are just a few changes we made, but we’ve got even more in the pipeline: more data encryption, site monitoring, and scaling the system based on growth rate.  I’ll post another follow-up once we tackle those shortly.