I've written about book publishing earlier at my personal blog. It is an interesting yet difficult business. I sort of stumbled into the world by chance. In this post I want to share some of my learnings.

Long story short I wrote a little Webpack cookbook with Christian Alfoni. That led to an idea of a bigger book. Initially we pitched that to a real publisher. After long negotiations we got a no. That didn't stop me. You can see the result here.

Even though the book hasn't been a great financial success, it has proven its benefits. There are multiple reasons for this. For instance having all your content open might not be the best idea for a beginner author unless you have some way to upsell. This is something I'm going to experiment with to see if having at least some of the content closed makes a difference.

Tackling Big Problems by Yourself #

I am aware a lot of beginner authors do a lot worse than me. The problem is that when you are starting out alone, you have to tackle big problems by yourself. Simply put even if you could write but fail at other important tasks, such as marketing and sales, it won't work. If you wrote an excellent book and people failed to find it, it would still be a failure, at least financially.

Note that you can, and probably should, outsource some of the book related tasks. You can find people to proofread your material for relatively cheap. Even if the reader knows nothing about the topic, you will likely get a bunch of grammar fixes to make. Same goes for crafting landing pages, marketing material and graphics. A professional can simply do better work, faster.

Extra Challenge for Non-natives #

As a non-native author you'll encounter an extra challenge in the form of grammar. As a Finn I tend to be quite blind at articles. I miss some at times. My writing style has likely been inspired by my culture as well. That's something that's hard to tone down. On the other hand that can be treated as a strength. Sometimes it's good to be a little different and stand out.

As a first time author going through an established publisher could be a good option. They'll deal with some of the hard parts. You will pay for this quite literally, though. And there are no guarantees for success. At least this will make you familiar with the process. When you decide to self-publish, you already know some of the ropes. As a result you aren't starting from the scratch anymore.

The economics of self-publishing can be more rewarding. There are more aspects to worry about but the economics make up for that. Roughly put you might need to sell six times the books through a real publisher than otherwise. This means you can reach decent income even with modest sales.

To give you a better idea, consider the figures below:

Traditional publisher - 15-50% royalty, closer to 15% normally and can be less even

Leanpub - $0.50 + 10%

Gumroad - $0.25 + 5%

DPD - $10 per month

Shortly, the more responsibility you take, the more you get paid for it. But this assumes you can deal with all the parts involved. Having a great royalty rate doesn't help if the book doesn't sell.

Especially with something like DPD you would be raking most of the profit to yourself. But as stated earlier, the cost is usually elsewhere. The benefit of Leanpub is that they offer a decent landing page for your book and support Markdown based authoring.

One potential problem is that you don't get direct access to your clients. This makes it more difficult to grow your personal mailing list than it would have to be. There are likely good reasons for this, though.

It is hard to underestimate the importance of a good mailing list. It is an amazing way to reach your audience. There are an entire set of techniques related to growing them. I am not an expert when it comes to mailing lists but I can see the value. Beyond marketing they actually allow you to help your audience directly, get feedback and so on.

Control over Output #

You can get output similar to Leanpub through something like Gitbook. If you have the skills for that, you can customize the result as you want. You can sell the result through Gumroad, DPD, and such. You will get more control over the sales process and can set up the sales funnel just the way you want it. I believe growing your mailing list becomes easier this way.

Benefits of a Proxy #

I feel selling is one of the smallest problems, especially if you go through a proxy. If you deal with it yourself, you will have to deal with things like EU VAT. That will get very complex and time consuming fast. It is likely a better idea to leave these kind of details to companies that have them sorted out.

Going Dead Tree and Beyond #

Note that services like Lulu allow you to get actual dead tree books done. The obvious disadvantage of this is that it becomes difficult to push updates. Lulu also gives access to major digital bookshops, such as Amazon, B&N, and iBooks. This means you'll need to have your book content fixed apart from grammatical fixes, though, as these platforms expect your book has an ISBN.

Financial success is only one potential benefit of writing a book. It will actually force you to become better at writing. Even though I'm far from top notch writers, I feel like my writing has improved. At least I'm faster at it, and it takes less effort. In addition I have gained contacts I wouldn't have otherwise. And, most importantly, writing a book has opened an entire new world to me in the form of opportunities.

Even in the worst case I have established a source of some level of income. The book seems to sell consistently and I have some tricks in my sleeve to improve on that. Better yet, I have made a dent to the market. It will be far easier to develop another book should I want to.

Having a book in your CV doesn't hurt either. The next time I do a round of interviews, I have an ace at sleeve. A book adds to your credibility and might be the factor that will help you to get the job. At the very least you will have a stronger bargaining position when negotiating over the financial bits.

What Would I Do Differently? #

Just like with software projects the easiest thing to mess up is scoping. It's difficult to estimate how long getting things done actually takes. This is exacerbated by the fact that as a first time author you don't have a frame of reference. Based on this experience I would say it's better to aim for a short guide, say 30-50 pages, rather than shoot for the moon from the first go.

It is easier to expand than to cut down. Go for a short, quality book rather than something long and shoddy. Your readers will thank you.

Experiment at Moderation #

One interesting aspect of self-publishing is that it allows a wide range of experimentation. I probably went too far with that at some points. Instead it might be a good idea to try to fix your table of contents as soon as possible. This is just to avoid the amount of rework needed. Sometimes there's no way to avoid that but as they say "fail to plan, plan to fail".

Ideally you wouldn't have to iterate a lot on the content. I know this sounds like waterfall. It's easier from a reader's perspective, though. If nothing is ever done, how do you know when to read? At some point a book has to become ready. Editions are ideal for bigger changes. That's the way the ISBN system has been designed.

You could say there's an interesting conflict between the need to move fast and the need for a stable result. Platforms, such as Leanpub or Gumroad, allow this sort of experimentation. As your book grows, it doesn't hurt to become more conservative in your approach. For instance I've made conscious effort to move towards a more stable release cycle.

One of the big challenges of being a technical author is that the scene changes all the time. If I started to write my book right now, I would perhaps choose some technologies covered a little differently. Especially in front-end development even a month is a long time. That puts extra pressure on both authors and readers.

It can be hard to accept that your book is obsolete in some ways as soon as you publish it. That's something for technical authors to endure.

The Busy Coder's Guide to Android Development is an interesting alternative to the common approach. The author is selling his book as a subscription service. It's a massive book, over 3,300 pages. Subscription would give you access to the newest content.

From business point of view recurring income is one of the greatest things you can achieve. The problem with traditional sales is that it's one-off. If you want more income from the same client, you would have to sell another offering or try to upsell your current offering in some way. You could for instance try to produce a video course or sell personal consulting to complement your base offering.

A subscription based approach is more involved. It implies the need for continuous work. I believe that can work when scaled to a sufficient volume. As always, the problem for first time authors is in reaching that critical mass required to make it work.

I went for an open approach in my first effort. The greatest advantage of this has been an immense amount of visibility. Of course translating that to sales is another story. If I started now, I would likely start with a mixed approach. Have something valuable behind a paywall to encourage sales. Perhaps a part of the content could be exclusive to the paid version only. Some keep all of the content closed.

There's likely no one right answer to this question. As the content has been available in an open format, that has enabled external contributions I would have missed otherwise. Given I'm a solo author, that has been a massive help. Now everyone gets a better book. This is something I am very happy about.

Even though publishing a technical book is surprisingly simple, actually succeeding at it is another story. There are a lot of things that could go wrong. Don't get discouraged, though. I believe that persistency, and the willingness to learn and adapt, will yield results at some point. Very few succeed with their first book anyway. So be prepared for another.