Home Blog Post-Launch Prep

Post-Launch Prep

Poornima
Founder, Femgineer
· March 17, 2010 · 1 min read

This is a follow-up to my prior post Pre-Launch Prep.  First, pat yourself on the back for making it through the launch!  Now let’s …

This is a follow-up to my prior post Pre-Launch Prep.  First, pat yourself on the back for making it through the launch!  Now let’s focus on next steps.  The product team’s job is to create and design features that will keep users engaged, and engineering team’s job is to make users happy.  Happiness == (bug free  && accurate data && responsive site).

 

1. Squash big bugs first!

Grep the logs and count the number of Exceptions or Errors then have it!  Best to create a nightly script to tally up Exceptions and Errors so that you don’t have to type the same grep command everyday.  You also want to check the user forums for discussions on bugs and talk to customer service representatives.  But before you begin doing a big fix make sure that the bug impacts a majority and not a vocal minority.

2. Get down and dirty with data.

 

Depending your product you might have data accuracy issues.  The easiest first step is to hit the production db and make sure the data that is being pulled in is correct.  If it is then you know there’s an issue farther upstream i.e. business logic or rendering.  If the db is wrong then you’ve got an issue with storing data, which could be caused by a broken link somewhere in the front to back-end flow.

3. Prioritize performance.

Everyone is always touting the vices of premature performance optimizations, which is a valid point, especially in a startup where you are resource and time constrained. You don’t need to optimize from the start, but you do want to build infrastructure to measure your site’s performance.  Performance is both a front and back-end issue.

  • Front-End: your page load time is abominable because you’ve got lots of graphics that haven’t been sprited, have browser interoperability issues, or network latency sucks because your user bought the cheapest DSL package…
  • Back-End: sure you’re using ajax on the front-end, but if each request is hitting the db and you’re pulling in thousands of records no point in being asynchronous…

Figure out where your bottlenecks are, and then tune it up!

Enhanced by Zemanta
Pocket
Share on reddit
Share on LinkedIn
Bookmark this on Digg

← Momentum All posts jQuery Basics →