This week we are talking about changing your mind. As your web app evolves, sometimes new information comes to light, and you need to be able to change your mind.

  • 0:54 For example: here at CodePen, we started out with two kinds of accounts: free and PRO. At some point, we had a discussion with a VC where they told us to give everything away for free. Build the user base and worry about pricing later.

    That idea sparked an internal discussion, and we almost ended up doing exactly that. But we didn’t. We decided to wait.

  • 3:48 The reason we didn’t end up making all the features available to free accounts: Tim just didn’t feel good about it up front. He believed we should look into the data, and not just trust our gut reaction.

    So we sent out a Wufoo form and asked our PRO users the #1 reason they signed up for PRO account. The response came back: “Private Pens”. So we scrapped the plans because we weren’t willing to sacrifice our financial future just to grow a user base.

  • 6:10 There was another feature we originally kept locked to PRO accounts: multiple resources inside of a Pen. After about a year, we decided to open it to all users.

  • 10:23 “It’s good for us to not stand in the way of you making awesome things on CodePen.”

  • 10:51 The main reason we ended up making that feature available for all users was the feedback we got through support. Users were asking for it, so we changed our mind, and got nothing but applause from our users.

  • 12:00 At some point, we decided we needed to change our web framework from Sinatra to Rails.

    “It’s easy to change your mind, but you need to factor in the cost of the new decision.”

  • 13:32 Another example that was a lot of work – but was a great change – was when we moved from Socket.io to Faye. It took month of dev time to convert, but in the end it was a good decision.

  • 15:28 “A re-factorization of your code is changing your mind, but at a slower speed, because you can do it incrementally, it’s not this big bang thing that happens.”

  • 16:03 We also changed from Resque to Sidekiq for queuing: mostly because the cleanliness of the Sidekiq codebase. (Queues are little tasks that need to be run)

  • 19:33 We had been hosting our error reporting service with an open source project called Errbit, but we ended up changing that to Honeybadger.io. For anyone not familiar, error reporting is a backend service that allows your errors to make it out of your application and into a notification system so that you can analyze them after the fact without having to comb through error logs.

  • 20:44 The main reason we changed our minds about our error reporting app was the time we saved by going with a service like Honeybadger.io: it frees us up to focus on developing CodePen instead of rolling our own error reporting system.

  • 22:08 Using operational transforms with Google Diff-Path-Match

  • 23:32 It’s important to agree as a team when making changes. Come together and discuss the services you’ll be using and the best way to use your time.

  • 24:45 For our big Teams feature, when we launched it, we decided to do a soft launch. No big splash or marketing, it was just live on the site ready to go. We started out charging $199/month for teams (10 users), but eventually changed that price to $40/month (5 users) based on the low number of signups, and feedback we got from our customers.

  • 29:30 So how did we decide on pricing? We’ve never had a formal discussion about pricing before, so you’ll hear it here first.