Codeulate.

On February 1st I released a screencast for sale called Vim for Rails Developers.  It was the first and only product of my new company, Codeulate Screencasts.

Since then, I’ve sold 148 copies of that screencast at $9 each.  After expenses I’ve been left with over $1,200 of profit.  Honestly I’m extremely pleased.  For my first crack at this, this feels great.

I was inspired to try this venture thanks to the inspiring and informational writings of others.  As such, I feel compelled to share the little I’ve learned, so that other entrepreneurs might enjoy the same benefits I did.

Be warned: the title of this post is admittedly a false promise.  I’m not sure if doing what I did will let you sell a hundred screencasts (or any, for that matter).  I only know it worked for me, and that I hope it will work for you too.

Things (I think) I did right

I chose a topic in which I was already an expert.

On my product page, I tell people “I spend every day writing Rails code in vim, and I’ve optimized the heck out that process. The screencast contains the best of what I’ve learned for creating and editing Rails code at top-speed.”

That stuff is true!  I work full-time as a Rails developer, and I’ve been a vim user for several years.  I’m also a nearly compulsive optimizer (I’ve aliased ‘ls’ to ‘a’ because it saves me a keystroke).  After a year of honing, my editor and environment are extremely customized to support the sort of programming I do.  I’ve shared these tips with others, and seen the subsequent boost in productivity they had.  When I was brainstorming possible screencast topics, this was an easy choice.

I let someone else worry about the infrastructure.

My site runs on Shopify, accepts payments through PayPal and Google Checkout, and handles digital delivery with Fetch.  I set the entire thing up in maybe three hours, and it requires literally no action from me to process orders–I just get the best email ever when it’s complete.  Using these services let me focus on what was important: getting my product out the door.  You ain’t done jack until they can pay for it.

I made the best damn product I could.

I probably spent 50 hours creating my first screencast.  I dragged myself to the office on weekends so I could focus better.  I tried really, really hard to make something useful.  So far, it looks like I did: feedback has been overwhelmingly positive.  I have no doubt this was the most important element of my success.

Things I screwed up (an extremely incomplete list)

I didn’t realize how valuable other peoples’ reviews were.

My first attempts at marketing involved sending emails about my screencast to ruby group mailing lists.  This got me my first handful of sales from several different lists.  In one of the them, a member replied that he had bought the screencast and found it well worth $9.  I made ten times as many sales to this list as the others.

Through dumb luck, Peter Cooper (really nice guy, by the way) saw a tweet about my screencast and offered to write a review on Rails Inside.  I figured this would be good for sales, but wouldn’t have guessed that 40% of my people purchasing my screencast would come from this review.  Oh, and another 30% from this other review, published a short time later.

I’m starting to think the second-best thing someone can do for me is to buy my product; the best is to write a review of it.

I didn’t show an early draft to anyone.

Several reviewers and survey respondents felt the very first section of the screencast went on too long.  The consistency with which people mention this suggests that I could have gotten this feedback by soliciting just a few reviews before launching.

Things that surprised me

I’m surprised by just how good it feels to get ‘new order’ emails.  I’m surprised by how bad it feels on days when I don’t get any.

I’m surprised by how many non-Americans are buying my screencast.  Overall, 59% of my orders have been outside the US, primarily to Australia, Brazil, Germany and Great Britain.

I’m surprised by exactly how much work is involved with actually shipping, and how it all feels worth it when I do.

The next thing

Inspired by my success so far, I’ve released my second screencast! It’s called Building a File-Upload App with Rails and S3, and I’m extremely pleased with how it came out.  I’ve used everything I’ve learned from my first screencast to make this one even better, and overall I think it’s quite polished.

Speaking of learning from the past: if you’re a blogger willing to write a review, email me and I’ll send you a free copy.

Thoughtbot‘s factory_girl has recently gotten a terrific new feature: callbacks.

They look like this:

Factory(:user) do |u|
 
  u.after_create { |user_instance| do_something_to(user_instance) }
 
end

Now, when you use Factory(:user) in your tests, the do_something_to method will be called after the user is saved in the database.  Also notice that you’ll be passed the instance of the user as block parameter.

There are two other callbacks now available: after_build and after_stub.  Their callbacks fire pretty much where you’d expect them to.

You can mix and match these callbacks on the same factory.  Multiple definitions of the same callback will be executed in the order you provide them:

Factory(:user) do |u|
 
  u.after_build { |user_instance| do_something_to(user_instance) }
 
  u.after_create { do_this_after_create }
 
  u.after_create { then_do_this }
 
end

I’m excited about this addition because of how much more flexibility this gives factory_girl.  There are some kludgy parts of my factories.rb files that will be more elegantly accomplished with these tools.

Accepting these little lambdas to be run later feels very lispy, something I take as a great sign.

For more usage details, check out the ‘callbacks’ section of the README.

And, if you’d like to read more about using Ruby’s blocks this way, Greg Brown has an excellent article on the topic (excerpted from his also-excellent book).