DEV Community

Cover image for My best book recommendations for solo developers
Takuya Matsuyama
Takuya Matsuyama

Posted on

My best book recommendations for solo developers

Learn from successful people through books and put immediately them into practice.

Hi, it’s Takuya. I hope you are staying safe and healthy. Reading books is a significant habit of building successful products. There are a lot of articles you can read for free on the internet, which is interesting and helpful. But if you want to learn about a specific topic thoroughly, reading books is one of the best ways to get such deep and detailed knowledge. In this article, I’d like to introduce the best books I’ve read and found incredibly helpful, along with how I’ve put them into practice in my own product.

TL;DR

  • I’ve had many failed projects. Since started reading books, my project got successful.
  • Do not be satisfied with only talking about your ideas with your friends
  • Bootstrapping: Getting Real by Basecamp
  • Marketing: Marketing Lessons from the Grateful Dead by David Meerman Scott & Brian Halligan
  • Productivity: The Goal: A Process of Ongoing Improvement by Eliyahu M. Goldratt
  • Other recommendations
  • Put them into practice. Now.

I’ve had many failed projects. Since started reading books, my project got successful.

I’m building a Markdown note-taking app called Inkdrop alone since the end of 2016. The big reason why I successfully made it profitable (MMR=$7.3k) is that I’ve read books and put solely them into practice. I didn’t have a habit of reading books until 2012. I was able to build apps that attract a lot of people but I was struggling to earn money from them. For example, at that time, I was running a music recommendation app called walknote which has more than 130,000 registered users. Although the momentum was so hot, I was lack of ideas to keep it running by monetization, and then ended up closing it. It became a great achievement for my freelance career because it proves that I can build useful apps that attract people. However, I wasn’t satisfied with the result because I really wanted to become a successful indie developer. I totally burned out and finally realized that I have to learn from successful people, especially about marketing and monetization. I didn’t know which books I should read, so I read anything that looked promising.

Do not be satisfied with only talking about your ideas with your friends

My bad habit until building Inkdrop was that I was often talking about my ideas to my friends who were not quite successful (yet) as well as me. Because they didn’t know how to make a product profitable in their own experience, which means that they have the same problem with me. I was satisfied by winning an argument with them about building a successful business despite the fact that I’ve never done that. It’s just fun to talk about your idea and to get an agreement from people, and you get nothing more than that. Of course, it could help clarify your thoughts but it would never be proof that your idea/plan will work. In my case, it’s never worked. So, I stopped talking and started learning from successful people through books.

I didn’t like reading texts because it’s boring. I’d rather read mangas and watch movies. Besides, I used to assume that successful people don’t want to talk about their secrets of success. No, not all, but we’ve got great books that tell their true pieces of knowledge out there. When I found books are so inspiring me, I couldn’t stop reading them all day and night.

Getting Real by Basecamp

Getting Real

This book lighted my way to where I should go as a solo developer, and I still repeatedly check my highlights in it. I was once intensively affected by startup culture and entrepreneurship and strongly believed like “I have to become big like Steve Jobs! I have to take the whole world with my service like facebook!” Ouch. The book told me that becoming big is not the only way to be successful and there must be a way you can thrive and enjoy your life with software development. It’s all about how to bootstrap your SaaS business by doing less and focusing on only what really matters. Here are my favorite parts from the book:

What’s your problem? — The key here is understanding that you’re not alone.
If you’re having this problem, it’s likely hundreds of thousands of others are in the same boat. There’s your market. Wasn’t that easy?

Even if you came up with a novel idea, there are always people who have already done the same or similar idea. But do not be disappointed with that fact. It means that there are people in the same boat. The point is whether you can find anything that you can do 3x better than others for the itch.

It’s a Problem When It’s a Problem — Heck, we launched Basecamp without the ability to bill customers!

I also launched Inkdrop without the ability to bill customers.

Make Opinionated Software — They say software should always be as flexible as possible. We think that’s bullshit. The best software has a vision.
And remember, if they don’t like your vision there are plenty of other visions out there for people. Don’t go chasing people you’ll never make happy.

So I focus on making it solely as a personal Markdown note-taking app. I have been saying no to all the feature requests on team support, snippet support, file system-based sync support, open-sourcing, and on, and on. If I said yes to those requests, the app would have been too bloat and sluggish, and I could have no longer maintained it. My codebase is still maintained as simple and clean.

Don’t be a yes-man — You should only consider features if they’re willing to stand on the porch for three days waiting to be let in. We listen but don’t act. The initial response is “not now”. If a request for a feature keeps coming back, that’s when we know it’s time to take a deeper look.

People who are happy with the current functionality basically don’t say anything. You have to remember that fact when listening to people who ask you for change.

Everyone wants more and more features and saying yes is easy because you don’t need to think deeply about them. But it’s very important to focus only on what matters for you. In my case, it is what I want to use. That lets me keep myself motivated.

Less Software — Each time you increase the amount of code, your software grows exponentially more complicated.

This is significantly important if you are an alone developer. I extremely love deleting lines of code. Fewer lines are better. Users tend to say “please add this feature as an option because I personally need it” but I rarely say yes because adding more preferences always makes the codebase terribly complicated. I learned that bugs always emerge from the features that I don’t use. Preferences give room for new bugs to reside stealthily.

Ride the Blog Wave — Start off by creating a blog that not only touts your product but offers helpful advice, tips, tricks, links, etc.
Our Signal vs. Noise blog gets thousands of unique readers a week thanks to the helpful, informative, and interesting bits and anecdotes we post on a daily basis.

I can find many developers only write about their own products today. You made an app to solve your own itch. Then, you should have a lot of things to tell in a topic that your app solves. I love to build things, and I made a tool that helps my creations. So, I know a lot of things to teach about how to build software well. And I started blogging about that. It attracts many people without using ads.

There are many more golden words in this book. You should check it out.

Marketing Lessons from the Grateful Dead by David Meerman Scott & Brian Halligan (HubSpot CEO)

Marketing Lessons from the Grateful Dead by David Meerman Scott & Brian Halligan

We indie developers are like an artist. Because we make and ship unique things in unique ways. So, we can learn a lot of things from artists.

This book is about the legendary rock band called The Grateful Dead. You probably haven’t ever heard that old band. Me, too. Because they’ve never had hit records in the major music industry. But the band achieved elite success in the late 1900s, yet without appearing on TV, along with a lot of devoted fans who call themselves the Deadheads. How the band has attracted people is one huge case study in fan-based viral marketing for indie developers, just because their approaches are so simple and feasible to conduct without needing a lot of money, relying on powerful word-of-mouth of fans, not on mass advertising. By putting them into practice, I successfully got 14,000 signups so far without running pay-per-click campaigns or hiring a traditional PR firm to “get the word out.” What I did is just to share my journey on building my product on my blog and social media. The important thing is that you have to understand what telling your story means because most people don’t understand what to share, how to express like, and why it works — then stop writing. This book tells you about them.

[Grateful Dead from Wikipedia](https://en.wikipedia.org/wiki/Grateful_Dead)

The Grateful Dead’s concerts were completely unscripted, which meant that band members often made mistakes. (…) Their fans understood and accepted this as part of the Grateful Dead experience. After all, they were human, too.

So, you can be you. You don’t have to be perfect. Throw away your perfectionism. Building a product is like a long long unscripted live concert over months and years. You and your fans will never know what will happen next.

The marketplace is incredibly forgiving of mistakes — especially if a company owns up to a mistake immediately, explains how or why the mistake happened, and how the company is fixing it.

When you make a mistake, your users will understand you are a human, too. I often make mistakes and the users report it, and I say like “Oops, that’s a bug. Here is the patched build. Could you try it?” They are basically cooperative, thankfully. Don’t forget to say thank you to them individually in your release notes.

Stop hiding your personality behind carefully scripted announcements, press releases, and events. Be yourself, and encourage your CEO and employees to be themselves.

Indie developers tend to set up a new Twitter account for their product and to hide their personality behind it. People can’t see what you think, why you made it, what you get, what you are working on, struggling on, etc. I made the same mistake on my Twitter account, whose profile image was the app icon, tweeting only press releases in the early days. Who would want to follow such a mediocre account? Who can be a fan of your product? I stopped pitching my product so much, changed the profile image, and started to share meaningful tweets as possible.

The grateful dead announced tours to fans first and treated supporters to the best seats, driving passionate loyalty.

Give your best deals to existing customers. Tell your fans first. Show the people who invest their time and money in your company that you care.

To foster their loyalty, treat them as special as the band did. So, I announce the beta version to paid customers first, let them try new features, and have a discussion with them.

The way to reach your marketplace is to create tons of remarkable, free content like blogs, videos, white papers, and e-books.

I sometimes post videos on YouTube. In the first place, it was to cultivate more audiences in addition to my blog. But recently I found that the existing audience is enjoying them so much. Free contents not only attract people but also make them a fan as he says:

He told me that he was a user, thought who built the app, found me, then became a fan after watching my YouTube videos. So, remember that great product comes first.

There is more wisdom you can find in this book. You should check it out!

The Goal: A Process of Ongoing Improvement by Eliyahu M. Goldratt

The Goal: A Process of Ongoing Improvement

This book is about productivity. Running a product alone requires massive productivity. You’ve got a lot of things to do from marketing, user support, design, to coding, and you have to finish them while keeping yourself healthy. Ugh, time is always running out! You can find a lot of books about productivity, but most of them talk about very task-specific ways, like to-do management, scheduling, communications, etc. But wait, those are like cooking recipes. What is the fundamental skill for continuously improving your productivity by yourself? The answer is — do less. Do less coding, less marketing, less user support. That gives you room to do further eventually. That makes you different from others after months and years. But how? What does doing less mean? This book answers those questions in the Socratic way.

When you are productive you are accomplishing something in terms of your goal.

Think about what is your goal. Define what is the success. My goal is to do what I love as much as I want. Many people and companies say their goal is to make money. I was told that the goal of the company I was working at is to make money. But money is just a means for me. Because my projects are solely meant for myself, not for investors or stockholders. I love making things that solve my own problems. If other people also have the same problem, then I provide it as a service. I love making beautiful things. I love to see people enjoying my works. And I would love to do them until I die. So, when I am productive I am accomplishing building things faster and better. My goal is not to live in a gorgeous house nor to show off people how I am rich. How about you?

The book is a story about a manager, working at a plant, to solve its productivity problem by minimizing bottlenecks while simultaneously increasing throughput. Fortunately, we software developers basically don’t need to care about inventory because our works are digital which don’t take physical space. We also don’t have much operational expense as well because server costs are a lot cheaper than rent for office or warehouse. So, to maximize your throughput, all you have to do is to avoid or minimize your bottlenecks because:

Whatever the bottlenecks produce in an hour is the equivalent of what the plant produces in an hour. So … an hour lost at a bottleneck is an hour lost for the entire system.

That is true in solo development as well. When you got stuck on something for an hour, you lost an hour literally. The book tells a workflow to solve the bottlenecks:

STEP 1. Identify the system’s bottlenecks.

STEP 2. Decide how to exploit the bottlenecks.

STEP 3. Subordinate everything else to the above decision.

STEP 4. Elevate the system’s bottlenecks.

STEP 5. If, in a previous step, a bottleneck has been broken go back to step 1.

So, doing less means that you have fewer and smaller bottlenecks. The point is that anything can be a bottleneck, such as:

  • Software design
  • Physical & mental health
  • Relationships with your family, friends, colleagues, customers, etc.
  • Home & work environment
  • Equipment
  • etc.

It’s important that you have a daily habit of checking yourself if there is anything you can do with your bottlenecks because it all depends on yourself. You should know what is the biggest bottleneck for you at the moment. I’ve once written about how I’ve been improving my productivity in detail here:

Getting Real, the book I mentioned above clearly explains how to do less in terms of software design very well. What I recently did is to improve my work environment. I built an air quality monitor for my home office:

The low oxygen affects your mental capacity than you would imagine. I clearly feel that refreshing air improves my productivity by checking the CO2 level with the monitor.

More books?

If you have already read these books above, here are some great books for your SaaS business:

Put them into practice. Now.

I introduced three books along with what I’ve done based on the quotes from them. What I’d like to emphasize in this article is that the key is when you finished reading a book put it into practice immediately. Now. On top of that, do not do it in your way. Just do it in the exact way as possible as they say because you don’t know how it actually works in practice in your project. It’s not too late you change it after trying it as they say. Again, do. it. now. Do not be satisfied with only finishing reading books!


Inkdrop - Organizing your Markdown notes made simple

Subscribe Newsletter

My YouTube channel

Top comments (3)

Collapse
 
ghost profile image
Ghost

Great post and +1 to the recommendation of "The Goal", I studied industrial engineer in the university, and that book was one of the most eye opener books in those years, we spend multiple courses studying increasingly more complex models and optimization methods to balance lines of production, adding more and more variables to make "more precise" mathematical models and simulations; and one day it came this little book with its stupidly simple premise that gave great results it was almost like cheating, you really need that extra 0,001% of precision that is most likely error anyway? is really worth the extra complexity, work and drift from the core problem and solution?.

“A clever person solves a problem. A wise person avoids it.”
― Albert Einstein

Collapse
 
saulsilver profile image
Hatem Houssein

Great selection. I’ve read Getting Real and also Rework (more useful as a company).
I suggest Getting To YES, for a life-changer negotiation skills.

Collapse
 
craftzdog profile image
Takuya Matsuyama

Thanks for the suggestion, I'll check it out!