Efficient Rails DevOps (ebook) + experience from building my first paid product

Hey guys,

last weekend, I finally released Efficient Rails DevOps, my first paid product. It’s an ebook about provisioning Rails servers, deploying applications and managing production environments.

While I would not mind one or the other sell through this post, this is not my goal here. Instead, I want to share my experience in the form of four bullet points:

  • The book initially started out as a 5-day email course but soon grew into an (what I thought) about 10-page ebook. The finished product now has 138 pages (and I think the content is quite to-the-point). Looking back, it covers way too much content for a first-paid-product which I why it took me so long to write (just over a year). Given the nature of the topic, there really is nothing to take away without seriously lessen the book’s value but “start with a small product” really is an advice you should adhere to when building your first product.

  • Building a product is not always fun. There were times when I had to force myself to keep going. So by all means, do not rely on myths such as “motivation” or “momentum” when building your product. In most cases, it is simply a matter of constant effort.

  • I suffer from a chronic illness which means that I have to choose the things in which I invest my energy carefully. Having a dayjob, I wrote the book completely in my spare time so I had to neglect publishing articles on my website and growing my email list while working on it. This means that while I sold a great number of books on the launch weekend (about 4% of my subscribers bought the book), I could have sold way more books if my email list were bigger. As I have more time now, growing my list is my number one goal for the near future but I’d suggest that you do not start working on your first paid product too soon (or at least do not neglect providing value and growing your list while doing it).

  • Being sysadmin and developer for more than a decade, I develop and run all my backend stuff myself. This means not only my websites, but first and foremost an application that ties together Mailchimp, Mandrill, Gumroad, Google Analytics and my websites to create a smooth experience for customers buying the book or joining my email list. There are lots of automations going on in the background and this stuff is rather hard to test (and if it breaks, no-one can subscribe of buy the book). This application existed long before I started working on the book - otherwise I would not have cared to build it but I would have used known-to-work stuff (e.g. a wordpress site with the Mailchimp plugin). I know that developers have a strong tendency to constantly reinvent the wheel, but this is usually not the best idea.

Thanks for reading. I don’t know if this post will be of use for you, but I always love to read stuff like this :slight_smile:

@relativkreativ, http://www.relativkreativ.at

1 Like

Yup. If it’s any consolation, the 2nd one is much easier, and quicker.

I would suggest the opposite. Growing email lists takes time, and if you wait for some “perfect” moment, you will never ship anything.

A few of my subscribers buy my books, but many people who do so are not subscribers.

Good point. I guess what I actually tried to say was:

Do not start working on your first paid product too soon if this means that you have to neglect growing your email list (because of time, energy, whatever).

An email newsletter very targeted to the group you are making a product for can get you lots of feedback.
For example, you could write articles about different problems your product will solve. That lets you test how to market that feature AND might give you an idea of relative demand for different features.

E.g., with your RoR ebook, if you had an article on SPEED and another on SECURITY and the SPEED one gets more Opens AND more clicks (I’m sure you’re including microConversion events like “did you like this?” and “Learn more”, etc.) then this might clue you in to SPEED being a problem more people are interested in.


1 Like