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