Reaching an Audience

Two months after the first RailsCasts episode, I attended RailsConf 2007. I'd never been to RailsConf before and was eager to meet fellow Rails developers. This one was in Portland, Oregon which was only a few hours drive. The conditions were perfect.

I remember eating lunch and talking casually among developers around a table. “Are you Ryan Bates?” asked one sitting next to me, “I recognize your voice.” Several others at the table chimed in and said they also watched RailsCasts.

It was a surreal feeling being in a room with strangers who know you by your voice. The analytics told me that the show had over a thousand views, but that was just a number. Meeting others in person made it real. Every one of those views had someone behind the screen.

I continued to produce content every week. And at the end of that year, RailsCasts was featured in the Podcasts section of iTunes. I looked at the screen with a huge grin on my face thinking "I made that, and it's right there for everyone else to see." It was a great way to end 2007.

RailsConf 2008

Every RailsConf has its special moments, but the highlight for me has got to be RailsConf 2008. Rails was picking up steam, and there was a lot of excitement in the community. An idol of mine, Kent Beck did a keynote, and the cherry on top was the Ruby Hero Awards, an event hosted by Gregg Pollack.

I was surprised to be called up on stage to receive an award along with 5 amazing developers who contributed to the Ruby and Rails communities. Knowing that my work was appreciated by others was the best motivation I could hope for.

The Challenge of Free

I was often asked "Why produce RailsCasts for free?" and the answer is in the outro of many episodes: "I hope you found this useful." Hearing feedback about how RailsCasts helped someone was the best feeling in the world. Helping others was the reason for starting the series.

However, it was a serious time commitment to release an episode every Monday. Episodes took about an hour to produce per minute of video. At 10 minutes long it took over my weekends. I remember a handful of times I had to scrap an episode at the last minute and work overnight to release a new episode by Monday.

After four years of producing content for free while working full-time, I was ready for a change. I wanted my nights and weekends back.

The Plan for Pro

Turning RailsCasts into a full-time job seemed like a dream, but I needed to find a payment model that would support me. Charging for the same weekly episode that I was already releasing for free would be a step backward. If I'm working on this full-time, then surely I will be able to produce more content.

I decided to keep the weekly free episode and add two paid episodes per week. One was a "pro" episode that would often dive deeper into that week's topic. The other was a "revised" episode that brought older content up to date with the latest best practices.

By charging a monthly subscription fee to unlock everything, the value of the subscription would continue to grow along with the back catalog. This seemed like a no-brainer from a business perspective.

Branding

I changed the name slightly from "Railscasts" to "RailsCasts" to break up the word and make it easier to comprehend. I wasn't able to adapt the new name to the existing logo so I set out to make a new one.

The original logo was thrown together in 15 minutes. It involved picking a font and adding a play button in the "R" (it was about the same amount of effort that was spent on the old Avatar logo).

For the new logo, I wanted something with a retro arcade feel. I lacked the design skills needed, so I put up a bounty on 99designs. Here's what I ended up with.

The new logo looked sharp and more official, but looking back, it lost some of the charm of the original. If I were to do it again, I would go with something closer to the original logo and branding to ease the transition.

Along with the new logo came a new site design and a larger video format. I also integrated asciicasts into the site. These were text versions of each episode made by Eifion Bedford. He was a joy to work with, and I paid him to convert the pro content into text as well.

The Flywheel

It was time for the big day. On October 3, 2011, I deployed the new site along with the first RailsCasts Pro episode and $9/month subscription option. My goal was to reach 1,000 subscribers in one year.

That goal was reached in the first 5 days.

A month later there were 2,600 subscribers, and it showed no sign of slowing down. RailsCasts was on fire.

My dad likened it to spinning a large flywheel. The years of free content got the wheel going, and all of that momentum carried over to the paid subscription. I doubt this would be as successful without the initial free content.

I cannot take all of the credit for its success though. The community has been exceedingly generous. I heard several reports of subscribers who no longer used Rails but wanted to show their support. I seriously cannot thank you all enough who supported me.

With its successful launch, everything was lining up to make RailsCasts better than ever. However, every fire needs an important ingredient: the fuel.

An Aging App

In 2005 the PHP app I was developing started to show its age. Any change to the backend logic threatened to break multiple pages. It was the website for Artbeats, a stock footage company my dad started in 1989.

While hunting for a solution, I came across Ruby on the C2 Wiki where many developers sang its praise. I attempted to build a templating system in Ruby without much success when a new web framework caught my eye: Ruby on Rails.

A New Framework

I ran the rails command to create a new app and was immediately put off. "What are all of these files it generated?" At the time I wanted a flexible framework that allowed me to structure the code my way. I spent the first week fighting Rails to make it fit my style of development.

A tradeshow was approaching, and I needed to develop a minimal version of the Artbeats site for kiosk stations around the booth. I decided to give Rails another shot, but this time follow the Rails way of development.

Everything clicked. In two months the kiosk app was done, and I had a better understanding of how Rails was intended to be used. Convention over configuration is the "secret sauce" of Rails. The framework will do a lot for you if you stick to its defaults and principles.

Fueling Up

The Ruby community was kind and welcoming to the influx of web developers coming to learn this new framework. This sentiment stems from Matz, the creator of the language. A common expression in the community is MINASWAN: Matz is nice and so we are nice. This was the type of group I wanted to be a part of.

I found a home on the Rails Forum, initially to ask for help understanding Rails, and later to help others do the same. Every morning I spent an hour or two researching solutions to other's problems. The best way for me to learn was to teach, and I learned a lot.

I also enjoyed learning through screencasts. PeepCode by Geoffrey Grosenbach offered high-quality screencasts that were over an hour long. They were filled with useful information, but I found it difficult to sit through and grasp the concepts in the longer format.

Another screencast series that inspired me was Photoshop Killer Tips by Matt Kloskowski. These were free, bite-sized 2-5 minute episodes that were released frequently.

I wished someone would make screencasts that were developer-focused like PeepCode in the shorter format of Photoshop Killer Tips. So I did.

Starting Small

I started by applying principles I learned from agile software development: do the simplest thing that could possibly work, get feedback, and iterate on that.

I bought a $10 microphone and recorded a few rough screencasts to share on the Rails Forum. This helped me gauge interest to see what others thought without too much investment. There I also asked for ideas on what to call the series. "Railscasts" someone suggested.

I reached out to Geoffrey Grosenbach who was kind enough to sponsor the show through PeepCode. I then built a simple Rails app to host the screencasts, and within a month, on March 5, 2007, the first episode was released.

A Spark

Fueled by what I had learned helping others on the Rails Forum, and my own experience as a developer, I had seemingly endless ideas to record. But I wasn't sure if what I had released so far was hitting the mark. I was missing the feedback cycle mentioned earlier. Was anyone even watching?

At the end of one episode I requested the audience review RailsCasts on iTunes. To my surprise, the next morning I woke up to dozens of positive reviews. This sparked me to pursue screencasting further and turn it into more than just a hobby.

I invested in a better microphone and set up a small recording "studio" in a closet because it was the quietest place in the house.

(I don't recommend working in a closet)

An Episode Every Week

Sticking to the format of Photoshop Killer Tips, my original intention was to produce 3 episodes per week at 2-5 minutes each. However, programming is not as visual, and it can be difficult to explain complex topics in only a few minutes. As the episodes grew longer, I decided to reduce the frequency to one episode per week with the sweet spot being around 10 minutes long.

This is when I hit my stride. I released an episode every week like clockwork. My goal was to make a series that one could anticipate and depend on. I kept this up for years to come without missing a single Monday.

Priming the Pump

While I didn't realize it at the time, an important part of the initial success was mentioning RailsCasts in my signature on the Rails Forum. This simple act turned all of my previous posts into mini promotions. Many of the first viewers found their way by googling a Rails issue, stumbling across my post, and then clicking the link in the signature.

Once word got out, it spread quickly throughout the community. It turns out I wasn't the only one wanting short, frequent screencasts covering Ruby on Rails. The series was a hit, but I wasn't prepared for how far it would go.

Continue reading Part 2: The Fire.