What I learned from Pieter Levels about indie entrepreneurship

One of the first books I read on bootstrapping is MAKE by Pieter Levels. Pieter promises to share the techniques that allowed him to build two highly successful products (Nomad List and RemoteOK) that bring in more than $80.000 each month. In addition to sharing actionable advice he wants to encourage others to try the bootstrapped way of building businesses. In his words:

“I want to make bootstrapping great (again) #MBGA”.

Before we dive into any details let me say this: I was ultimately a bit disappointed by the book. Even though I’m a beginner I felt there weren’t many new ideas discussed in the book and some of the most important parts seemed to be missing. Overall, I would rate it at a 6/10.

Make Money by Teaching How to Make Money by Teaching How to Make Money

In the first chapter, Pieter uses the book itself as an example for the process he will outline in the following chapters. He put up a simple landing and ask for pre-orders. Thousands of people paid $26.99 for a book that didn’t exist yet. People who pre-ordered the book were able to give feedback on what should be discussed in the book and Pieter then started writing the book in public while simultaneously gathering more reader feedback along the way. Every time a new chapter was finished he sent it to all the people who pre-ordered the book.

This is certainly a cool idea but overall not really useful for beginners. He was only able to do this since he already had thousands of Twitter followers and was a well-known figure in the maker world.

If a nobody puts up a landing page and just asks for money certainly no one would be crazy enough to pay.

Moreover, I think the chapter is somewhat problematic because it’s a classic example of “teaching how to make money by teaching how to make money”. If you think about it, it’s even one level beyond that. He discusses how he made money by selling a book about making money by teaching how to make money in a book about making money.

Luckily, most of the following chapters are better.

The Process

According to Pieter the stages on the way to a successful bootstrapped business are:

  1. Idea
  2. Build
  3. Launch
  4. Grow
  5. Monetize
  6. Automate
  7. Exit

He has a chapter dedicated to each of these topics.


How advice on product ideation boils down to: scratch your own itch (solve your own problems) and if this doesn’t work do more interesting stuff.

He uses the example that he was only able to build Nomad List because he lived as a digital nomad himself. Now scratching your own itch is certainly a viable strategy. But it’s just one out of many and Pieter doesn’t discuss any alternatives. And “become a more original person” is not particularly actionable advice. I think I understand what he’s trying to say. To have good ideas, you have to actually do stuff. You can’t just stare at a whiteboard and hope that inspiration strikes you. It’s much easier to have great ideas while you’re doing something else. For example, when you’re starting a podcast you suddenly notice lots of small problems you could solve.

Moreover, I don’t think that his (most successful?!) business RemoteOK was scratching any of his own itches. (He has no employees, so a job board doesn’t seem like a problem to one of his own problems.)

However his advice to “always start from the problem, not the solution” and that “to get big, you have to start small” is certainly good to keep in mind.

Morover, he advises to create an idea list because “your mind is like a rice cooker for ideas.” In other words, you need to let ideas sit for a while before you should execute on them. Unfortunately, he doesn’t explain what you should do with your idea list. This is a problem I’m currently struggeling with. I have huge idea list and I’m not sure what projects I should focus on. So I was hoping for a bit more actionable advice on that front.

Another good advice he gives is that ideation should happen alone. In groups, there is always so much signalling and other distractions going on that rarely the best ideas have a chance to surface.

His last advice in the ideation chapter is that people shouldn’t be afraid to share their ideas because “there’re thousands or even millions of people with the same ideas as you. Ideas are a dime a dozen. Everything is about how you execute.”


Next he discusses how you can go from idea to product. His advice is to “build fast and minimal”.

He advises this strategy because many beginners get stuck in a phase of inaction due to their desire to do everything perfectly.

“Avoiding perfectionism is a skill you have to develop. You need to learn to be fine with everything being not fine.”

I certainly don’t have a problem with perfectionism (rather the opposite) but otherwise this is certainly good advice.

Further he advises that although your minimum viable product can of course be minimal, it should still be great and function. Later he even mentions that

“An email sign up box is not a product, it’s an email sign up box. Don’t launch it. That’s ridiculous. I see it too much and it’s completely useless.”

This is clearly in conflict with his example in the first chapter. His book didn’t exist at all when he sold it, so it was just an email sign up box.

As mentioned above, as a beginner you certainly have to offer something that works while if you’re famous you can get away with less. (These are my thoughts not his and how I resolve the conflict between his advice here and in the first chapter.)

Next he discusses the different strategies to build products: outsourcing, doing it yourself, having a big team funded by venture capital money.

He recommends building things yourself because venture capital money is often spent on nonsense (like “bean bags and ping-pong tables”) and outsourcing is a money pit and slows you down since you’ll have to write an email for every small tweak.

Building software products is no longer expensive (servers start at $5 per month) and hence bootstrapping a sustainable and less stressful alternative to the venture capital game.

He then shares some advice on how to learn how to code. In short: figure it out as you move along. “Just Google every single thing you don’t know.”

Further he recommends stopping worrying about what programming language to use.

“The people discussing what programming language is best are not shipping products. The people who don’t care what programming language they’re using are shipping products. They’ll use whatever tool they need, whenever they need it.”

Moreover, “a good tip to choose a technology is its age. If a technology has been around for a decade or more, it’s probably working well for people.”

So his advice is to “use whatever is easiest for you to learn or work with. And then switch whenever you feel you’ve outgrown a language.”

The rest of the chapter is devoted to an example how you could build a product without any code by tying service like Carrd, Typeform, and Google Sheets together using Zapier.

I thought the chapter was overall quite disappointing. There were a few bits of good advice but I felt as if he barely scratched to surface. There’s no real guidance or concrete recommendations which, I think, you need most as a beginner. When it comes to coding and the tech stack, his advice boils down to “just do whatever and however you like”. Uhm… okay. That’s not particularly useful if you’re staring at a blank page in Sublime Text.

He mentions services like Linode, Digital Ocean, Heroku, NGINX, and frameworks/programming languages like Ruby on Rails, Meteor, Laravel, and PHP that “make it easy to build products by skipping the ground work.” But he gives absolutely no recommendation or discusses them in any detail.

Of course, there’s no need to pretend to be an expert in everything. But I really expected that he would share at least his own approach in more detail. He doesn’t even mention how he starts a new project, how he plans it, how he decides on the code structure, how he makes it secure etc.


The next step in the lifecycle of a product is the launch. Launching means to make the existence of your product publicly known. You do this by tweeting about it and by posting it on relevant platforms like Product Hunt, Hacker News or Reddit. The goal is to create some buzz around your product which, in turn, makes it easier to attract further users.

Before the launch he recommends to “fix most bug”, to “add an email box”, to “add push notifications”, to “set up analytics” (Google Analytics, MixPanel, Amplitude, or Hotjar), and to set up a feedback box using Olark or Intercom.

I found his advice on posting your product on Product Hunt quite useful. For example, he recommends posting your product at 00:00:01 PST because at midnight the daily list resetted and thus you have more time to gather votes.

He further recommends to use emojis in the tagline. For example, you should write “The first 🤖machine learning 📷photo editor” instead of “The first machine learning photo editor”. Also he advises that it’s a smart idea to upload an animated GIF as your thumbnail which you can create, for example, using GIPHY Capture

There’s lots of further interesting advice like, for example, to write a first Product Hunt comment yourself to get the conversation starting and to check the comments regularly and give answers.

Similarly, he has good advice in posting your product on Hackernews. The key is to get 5 people to upvote it within the first hour because this already will be enough to get it to the front page and thus lift you above the other noise. Afterwards, you should just observe how users like it since gathering too many upvotes quickly will get you banned.

Another good advice for Hackernews is to maker your posts personal. Instead of writing “Petsy.com - The best food delivery for pets” you should write “I made a site that lets you subscribe to food delivery for your pet”.

Similar advice applies when you post your project on Reddit.

He briefly mentions that you should “tell your story”, for example, by blogging. It’s a bit disappointing that he doesn’t go into any details here because his success was primarily the result of storytelling. Most people discovered his products through his “12 startups in 12 months” story.

Last but not least he talks about getting press coverage. This section is really interesting because, I think, this is what most led to Pieter’s own success. Nomad List (and his “12 startups in 12 months” story) was quickly covered by big media companies and I think he’s still benefiting from these mentions.

His advice on getting press is to go through the list at Submit.co and find the email address of at least one journalist at each outlet. Then you write them a really short email:

“Hi Jody! I made a site that lets you subscribe to food delivery for your pet. Let me know if you need more info :)


and hope for the best.

The last piece of advice he shares in the launch chapter is to keep launching after the first initial launch. This strategy is known as “side project marketing”. The idea is that you build small projects that are somewhat related to your product and launch them independently. Each launch is a chance to get new eyeballs onto your product.


His advice on growth after the first initial launch is to stick to organic growth. A cornerstone of this strategy is the side project marketing mentioned above. Another useful strategy is to “build in public” which allows you to attract new users through transparency.

Otherwise, he shares common-sense advice like “make it easy for people to share your stuff by enabling pretty Twitter and Facebook cards and to use human-readable URLs

Somewhat strangely he also mentions that “good strategy to grow is to launch an API” only to mention a few paragraphs later that his own API led to lots of clones of his site and he eventually had to shut it down.

His conclusion on the “how to grow” question is “make a really useful and great product!” That’s certainly true but far from easy and not what I would call actionable advice.


In this chapter Pieter discusses that you should build with monetization in mind because this is the best way to validate if your product is truly useful. “Monetization is validation” is the mantra.

He further recommends validating ideas by adding a “Buy” button even if you’ve no working product. If people then click on the link, they can sign up to get notified if the product really launches. Again, this advice is clearly in conflict with his earlier advice to not just launch with an email sign up form and I’m convinced that beginners can really pull it off.

In the rest of the chapter he discusses different business models like

  • Pay-per-feature
  • ads (“stick to native ads”)
  • sponsorships,
  • patronage,
  • subscription-based memberships/paid communities, (“Subscription (or recurring) revenue is somewhat of a holy grail for entrepreneurs.”)
  • job boards,

and payment providers like

  • Stripe,
  • Braintree,
  • and PayPal (risky because PayPal is known for locking down accounts for minor issues).

He advises against using a combination of payment providers because this makes bookkeeping a lot more difficult.

Then he dedicates a whole section to bookkeeping and taxes. Unfortunately, his advice boils down to that “if you’re doing over $50,000/year revenue to pay up to $5,000 for a good accountant.

Pieter himself did set up a company in Singapore but still paid his taxes in the Netherlands for many years even though he’s living as a digital nomad. At one point, he even thought about launching “a service that helps you register your remote company in Singapore as an LLC”. And recently, he gave up his Dutch residency and is now, I suppose, a resident of Singapore.

So I’m sure that there’s a lot of interesting stuff he could explain. But he doesn’t mention these kinds of things in the book even though they would be interesting and valuable for aspiring bootstrappers. (Giving legal advice is of course always risky and shouldn’t be done by amateurs. But he could share at least his personal experiences.)


In the next chapter he explains that you should set up cron jobs to automate stuff. For example, he uses cron jobs (“robots) to

“Find the weather, internet speed, air quality from 25 different sources for 1,000 cities every hour of the day.”

or to

“Notify me by SMS when anything breaks or doesn’t work perfectly, like the server using too much CPU, disk space, or showing lots of errors.”

Moreover, he mentions that he likes to have developers on standby so that he can get help quickly whenever he needs it. He pays them $50+/hour.

“Where do you find humans? I usually hire my friends as temporary contractors, but you can also try sites like Upwork.”


The last chapter is dedicated to selling your business. Since this is currently not relevant to me, I skipped it.


He then ends the book with some encouragement.

  • You need to ship lots of stuff until you find something sticks. Launch lots of little experiments until you find something that gains traction.
  • You need to take action. “Repeated action is what it comes down to. Relentlessly taking action, iterating and trying for years, in some disciplines for decades, until you get to where you wanted to be.”
  • “Listen to your intuition. […] Take inspiration but do your own thing.”

The bottom Line

MAKE by Pieter Levels certainly contains bits and pieces of good advice. But I felt as if he’s holding back a lot of valuable information (how he actually comes up with and evaluates the potential of his ideas, how he builds his products, how he’s set up his company etc.). He’s not going into much detail and given the price of the book and his reputation I expected a bit more.

All the advice he shares could probably be compressed into a small number of Twitter threads or a blog post like this one. In fact, I think that if you just read his own summary, you probably know already 90% of what is covered in the book.

What the book is good at is “motivational ra-ra” and encouragement. If you’re looking for actionable advice, there are probably better books.

(As an aside, note that there are lots of typos and grammtical errors in the book. Given that he earned already more than $200.000 with the book, I think he should pay a few hundred dollar to someone who carefully proofreads his manuscript. But I personally don’t care much about grammar and typos and hence they didn’t affect my opinion.)

Written on September 24, 2020

PS: If you're interested in following my journey, sign up below: