Lessons learned from publishing on Gumroad

24 Mar 2022

(This post was originally published on Indie Hackers, but I thought some of my regular blog readers might find it interesting, so I’m publishing it here, with light edits.)

One month ago I published my first ebook on Gumroad. I went into the process with absolutely no idea what I was doing, and no real idea of what to expect. I wanted to see if I could write and sell a book, so I struck out with that goal in mind and winged it all the way to the finish line.

Now that I am through the writing and publishing process, I thought others who are considering writing an ebook (especially a technical book like mine), might find value in hearing about my process along with what went well and what could have gone better.

Background

I started consistently publishing Ruby on Rails-focused programming tutorials on this blog in June of 2021. I was fortunate that my articles picked up some traction organically, primarily through high rankings for a couple of articles with very low competition, popular terms for folks looking for information on new pieces of the Rails stack.

From June to December, traffic grew from < 1,000 visitors in June 2021 to > 5,000 visitors in December of 2021. Most of this growth came from Google search traffic, with Twitter and Reddit making up the bulk of the rest.

In addition to the organic search traffic my tutorials attracted, my work was shared regularly on social media (especially Twitter and Rails-focused subreddits) when the niche technology I write about was mentioned.

I had some nice traction and some clear indicators that people were finding my work useful, and I knew that I wanted to write something more substantial than the quick, surface-level content that can fit into a single tutorial.

So, in November I tweeted a rough chapter list to see if there was any interest in a longer form version of my writing and it went about as viral as any tweet can with my tiny Twitter presence (maybe 200 people at the time of the tweet). I took that as another good sign and got to work.

Writing process and pre-launch

Since the book is a step-by-step, line-by-line walkthrough of building a Ruby on Rails application, my time “writing the book” was split in half. I first wrote all of the code for the application, taking detailed notes of each change and splitting the code into what felt like coherent “chapters”. I did not write any prose during the first phase — my chapter outlines were code blocks and file names.

Once I had the application built and each code change captured in my rough outline, I went back through my notes and stepped through each change, writing rough explanations for each block and testing the code for completeness.

After the code and rough outline was assembled, I stepped through each rough chapter and started writing detailed prose and telling the story of each chapter. This process of build > code notes > prose was basically the same as my process for the tutorial blogs I’d been writing for months, so while it was daunting to write 11 coherent, sequential chapters, it helped that the production process felt familiar.

After the detailed prose writing was finished, I went through several rounds of copy editing and polishing, along with 3 full run-throughs of each line of code to ensure accuracy and consistency. During this pass, I also captured all of the gifs and images I needed for each chapter to give readers landmarks to compare their progress to the book.

Once the polishing rounds were past, I sent out the book to beta readers (see below for details) and then spent a month waiting for feedback/incorporating feedback from beta readers.

All told, I spent approximately 150 hours coding, writing, and editing the content of the book before launch. Of that time, roughly 60 hours was coding, and the rest was writing and editing.

Beta readers

In early January, I wanted to give myself a clear deadline to finish the beta draft, so I sent out another tweet asking for early readers.

My idea here was to both get feedback on whether the content was useful/confusing/interesting/awful from strangers and to have an opportunity to test out the web application that I built to host my book (see below for details on that).

Approximately 30 people reached out expressing interest in being beta readers (this felt like a great number given my limited social reach) and I selected 10 to send the book to. I had never run a beta reader program before and had no idea what to expect, but I decided keeping the list of beta readers relatively short would be easier to manage and would keep me from being overwhelmed with feedback.

I eventually received feedback from 5 of the 10 beta readers, 3 sent very detailed feedback and 2 sent more general feedback, all of which was useful. The detailed, chapter-by-chapter feedback was most valuable, and I think I was quite fortunate to get as much detailed feedback as I did.

In retrospect, I should have done more to vet my list of beta readers — without getting lucky with a few very kind folks I may have been left with no early feedback on the book because some of the people I selected were not ready for the commitment required to read and offer feedback on the book.

Publishing the book as an app

I have been coding for a long time, and I have bought quite a few programming ebooks (and plenty of physical programming books) over the years. When I started writing, I assumed that I would publish my book as a PDF, with basic syntax highlighting and otherwise kind of a meh experience. This is how every programming book I’ve read over the years was packaged, so that’s what I went in thinking about.

As I converted my content to PDF, I was very unhappy with the reading experience. I write long, step-by-step code tutorials, which naturally means my readers are looking at a lot of code, and copying/pasting much of it into their editors as they follow along with the tutorial. On my blog, readers can click a “Copy” button to copy and paste each code snippet, which makes a difference when working with dozens of code snippets in a tutorial.

I also rely heavily on gifs to provide visual check-ins on what the application looks like throughout the book and how the elements we build work — click this, this happens, click that, that happens. These visual elements make long coding tutorials much more consumable.

Both copy/pasting with a click and embedding gifs proved to be extremely difficult to accommodate when publishing the book as a PDF.

I started having nightmares about finding typos the day after launch that day one purchasers would all see forever, and worrying about how to distribute major book revisions in a coherent way or otherwise improve the content of the book after launch in a way that ensured readers would be able to find it.

All of this weighed on me for weeks, and I ultimately decided the solution was to build a web app to serve my book as basically a fancy blog with user authentication in front of it. This is the silly engineer thing to do – build a whole dang web app to serve some static text content to readers, but that’s the path I chose.

Ultimately, building the simplest version of the book-as-web-app took ~15 hours to code and deploy to production. Much less than writing the book, but kind of a painful distraction while I was in the polishing phase and finishing the app was a blocker to delivering the book to beta readers for a few days.

I’m now on the hook for ongoing maintenance of the book’s web app, which has been minimal so far, but is something I have to be mindful of as long as the book is relevant.

Fortunately, readers have been happy with the delivery method of the book — so much so that I’m working now on building a SaaS to help other technical writers publish their books to the web without having to code a reading app from scratch like I did.

Launching and marketing the book

My very sophisticated marketing plan for the book consisted of a tweet thread drafted up the night before launch, along with a 20% discount off the list price during the first ~week after launch.

I sent out the thread on February 23rd with no idea what would happen.

My realistic goal for launch was to sell one copy of the book. My “I think I can do this goal” was to sell 20 copies of the book, and my “there’s no way I’ll hit this” goal was to sell 50 copies of the book in the launch period.

My sales chart for the launch week looked like this:

I hit all of my goals, which was a huge surprise.

A few things that worked during the launch week:

• The initial tweet thread garnered a lot of attention and retweets from folks with much larger followings. The trust I’ve built up with my free writing gave me enough credibility for others to boost my paid work
• I sent one more tweet on March 2, one day before the discount ended letting folks know that the discount was ending and that I was one sale away from my stretch goal (which was true)
• I curate a monthly newsletter for Rails developers and sent out March’s edition on March 1 with a link to buy the book and a note about the discounted pricing
• I added a share link inside the book to make it easy for folks enjoying the book to share it with others
• I got one sale from a free listing on dev.to, which took ~30 seconds to create. Every little bit helps.
• I offered purchasing power parity pricing discounts and about five people reached out to get a discount based on where they live. I used a spreadsheet I found online to calculate discounts, which worked fine.

All of my sales but one came from Twitter and direct links:

As you can see from the charts, after the initial burst of sales from the book launch tweet, sales dropped to basically zero until I started talking about the book again in my newsletter and on Twitter at the end of the discount period.

Unless I’m actively promoting the book, sales will be very slow!

Post-launch period

In the three weeks since the discounted launch period ended, sales look like this:

Five total sales, with no more than two in any given day. The two sales in one day came on a day when I published a blog that included a brief blurb about my book at the end — probably not a coincidence.

In this time period I have also had one buyer ask for a refund, which I immediately granted and then helped the person work through the setup issues they had in their environment that made them unable to get value from the book. I wish I were at zero refunds, but 1 out of 63 feels okay.

Lessons learned

Ultimately, I classify the launch of my book as a success based on the original goals I set for myself.

Writing a book was not very profitable on a per hour rate (nearly 200 hours for $3,000 is not a great return compared to my hourly contracting rate!) but I greatly enjoyed the work and I knew from the outset that this work was an investment in myself, rather than for immediate financial gain.

I learned a lot, improved as a writer, built a fun web app, created a product that a few people wanted to pay for, and earned my first real dollars on the internet, which feels like a nice milestone.

If I were going back to do the process over, a few things I would spend more time on:

• Working more on marketing. While I never planned to earn a bunch of money from the book, I know that I could have gotten more from the book’s launch with more effort put into promoting the book.
• Building a system to ask for reviews. I have zero reviews or testimonials on the book right now, which hurts my ability to sell it to people that do not know me. The price tag is pretty high at $70, which is a big investment to make without more social proof. Having a process in place to follow up with buyers and ask them for feedback and reviews would have helped keep sales up after the initial launch excitement died down.
• Up front planning. Writing a book is hard, even when the book is really just a very, very long tutorial. I struggled to keep my ideas clear and ended up scrapping code and spinning my wheels on unimportant parts of the book because I did not go in with a clear enough plan for every stage of the application. A smoother writing process would have meant an earlier launch and a less stressful writing and editing experience.