Self-publishing a technical e-book

Martin McBride

2021-06-22

Over the past year or so, I have written three e-books on various topics in Python programming. Although I certainly don't consider myself to be an expert on self-publishing, I have learned a bit in this time, so I will share it here. I hope you might find it useful.

This article covers four stages:

Choosing and researching the topic.
Writing the manuscript.
Making it available for sale.
Generating sales.

I have found the whole process takes me about 3 months, if I put most of my hobby time into it.

But first, why do it?

Why self-publish an e-book?

In my case, I have been writing technical posts on various websites for quite a few years (I created my first website in 1995), mainly as a way of learning new topics for my own benefit. I have thought about writing a book from time to time, but I never got around to it for a couple of reasons. I wasn't convinced that anyone really wanted books any more, and I didn't want to invest a huge amount of effort in proving it.

But my current website, pythoninformer.com, was starting to generate a bit more traffic than any of my previous efforts, and I noticed that some similar sites were offering e-books as a way to monetise their traffic, so I decided to give it a punt.

Of course, there is still the option to use a traditional publisher, so why self-publish? Well, if you are already publishing your work on a website, and accustomed to publishing articles as and when you write them, traditional publishing doesn't look so attractive. The idea of asking some gatekeeper for permission to publish your book, waiting for months for it to happen, and then letting them keep 90% of the profits, makes no sense.

But keep an open mind, 10% of a lot is better than 100% of not very much, so if you think a traditional publisher can help you reach a mass audience, go for it.

Another consideration for technical books is that you might be the sort of writer who likes to use a lot of pictures - they often explain things better than words. Traditional publishers tend to want to keep open the possibility of printing the book. Colour images aren't cheap to print, so you might be forced to compromise your book.

Choosing and researching the topic

Writing a is probably going to take a lot of your spare time for weeks or months, so it is a good idea to choose a topic that you are interested in. It helps if you know something about the topic too, although it doesn't have to be a subject you know inside out, just so long as you know enough to be able to research it in a reasonable time frame.

Set against that, you are hoping to sell your book, so you will need to pick a subject that people are interested in buying. And you should think about how you might reach your audience and persuade them to buy your book over similar books that might be out there.

If you are writing with the aim of monetising a website, it might well be that the traffic you are getting will indicate what topics to pursue. If most of your traffic goes to a handful of pages, that might be a good indicator. In my case, I have opted to create books on some specific Python programming topics that seemed popular on pythoninformer.com.

With your topic chosen, it is time to do the research. It is a matter of personal choice whether you research every aspect in detail before you write a single word, or start writing immediately and fly by the seat of your pants. Most people choose somewhere in between. From the point of view of keeping yourself motivated and seeing an and to it all, it useful to have a rough idea of most of your chapter headings, and some idea of the number of words you intend to write. Have a look at other books of similar complexity to gauge that. There will typically be 250-300 words per page in a typical book, so if your book is going to be about 100 pages expect to write up to 30,000 words.

I find a mindmap to be a good way to work out the basic chapter structure, with a few topics listed under each chapter. For the more detailed notes I use OneNote to collect websites, snippets, and ideas about the structure of each chapter. But there are lots of alternative products, including some specifically for authoring (Scrivener and similar products). Whatever works for you.

Writing the manuscript

The most time consuming part of writing a book, of course, is the mental process of expressing yourself in words. In some ways, the method you use to record those words is secondary. Almost any text editor, word processor, or pen and paper, will allow you to so it, and no fancy application is going to write the words for you.

But there is a more important consideration that the editor, and that is the workflow. How does what you write turn into the published e-book. You can always change your mind about the workflow later in the project, but doing that will involve some tedious reworking. It is best put a little thought into the wrkflow before you start..

The thing to bear in mind is that at some point you will need to convert your document into one (or more) e-book formats at the end - such as epub, mobi or PDF. You can't directly write in any of these formats, because they are final versions of the e-book, designed to be read rather than edited. You will typically create your book in general purpose text editor and convert it to one or more e-book formats.

There are two main workflows. The first is to use MS Word (or you can use Open Office if you prefer). You can create a PDF document directly from Word, and there are various ways to convert Word to epub or mobi. If you are distributing your book via a service such as Smashwords or similar, they can automatically convert your book for you (see later). There are also plenty people who are willing to convert your manuscript from Word to a hand crafted epub document for a hundred dollars or so.

The advice when using Word is to keep it simple, no fancy formatting, just basic header and text styles, bulleted lists, and inline images. Anything more than that will not work well in an e-book.

The second workflow is based on markdown. Markdown is a pure text format, so you can edit using your favourite text editor (sublime, vscode etc). You use special symbols for text formatting, such as hashes to mark a header, asterisks for bulleted lists and so on.

I created my first book in Word, but now I use markdown, for several reasons:

It is a text format so you won't get any weird formatting problems.
It is easy to re-purpose blog posts as book content - my websites use markdown too.
It handles code highlighting very well.
Leanpub (my preferred publisher) supports it as their primary input.

There is also a great free tool called Pandoc which can convert markdown into almost any format in existence.

Making your book available for sale

There are quite a few options here. The most straightforward way to make your book available for sale is to put it on some digital download site (Gumroad for example). Set up an account, add your book, and start selling. The free tier is good enough to start with, so all it costs you is a small percentage of each sale.

The downsides are that it is entirely down to you to drive sales. Nobody browses Gumroad looking for programming books, so if you don't send people to your Gumroad page, you will get zero sales. And also, the purchasing experience isn't tailored to books (you don't get things like "look inside").

Personally I mainly use Leanpub for my books. They have a free tier, and just charge a flat 20% of the sale. But it is a dedicated bookshop, users can see previews, table of contents and so on. They also do a small amount of promotion and a monthly sale (although there is no guarantee your book will be included in the sale). Leanpub accepts markdown format, and does a very good job of converting it to other formats.

Many online bookshops now sell self published e-books in a similar way to Leanpub, again usually with a 20% fee. This has the advantage that more people are likely to visit these sites searching for a book so they can generate sales. So far only Amazon has made any sales for me, but it is early days.

In general though, each of these stores expect you to submit an epub format book that passes their own individual automated tests. Each store has its own rules too, so it can be quite time consuming to submit your book to all of them. Fortunately there are several services the will format your book and submit it to a bunch of the bigger online bookshops (including Amazon and Apple). Smashwords and Draft2Digital are two examples. The generally expect a simple word document as input

These services typically take an extra 20%, on top of the 20% the bookshop takes, so you end up with 60% of the sale price. That isn't bad considering it is almost zero effort, and I would recommend giving it a try. But in exchange for the automated submission process these services provide, you will be paying 20% commission for ever more, which could be an expensive decision if you end up selling tens of thousands of copies.

Generating sales

Whatever option you take, you will probably find that most of your sales are self-generated. I sell a few copies a month to people who have stumbled across my books on Amazon, but the majority are from people who have found one of my books via my website or social media, and gone on to buy it from Leanpub.

Once your book is complete, the real work begins...