How to Build a Startup Without Funding by Pieter Levels / https://nomadlist.com/ / https://gofuckingdoit.com/ / AI사진 툴

 

Presented at Dojo Bali http://dojobali.org, thanks to Michael Craig and Haren Tambi for hosting, Marc-Antoine Fonne for filming, Andrey Azimov, Clare Harrison, and Petr Suska for supporting. The popular narrative of startups is outdated. You don't need venture capital to build a startup. You do need a DIY attitude, a lot of persistence and become a generalist who can learn new skills like coding, design and marketing quickly. This way of building a startup is called bootstrapping and it's the coolest way to do it I think. The best thing is you don't need to rub up to venture capitalists to get funding, you keep ownership of your company and you have higher odds to make more money. The 7 stages of bootstrapping a startup: 00:00 Intro 6:58💡 Idea 11:58 🛠 Build 14:50 🚀 Launch 20:15 🌱 Grow 26:18 💰 Monetize 33:20 🤖 Automate 35:48 🚪 Exit Subscribe on YouTube:    / levelsio   Follow me on Instagram:   / levelsio   Follow me on Twitter:   / levelsio   Follow me on Facebook:   / levelsio   Read my blog: https://levels.io This event took place in at http://dojobali.org in Canngu, Bali on January 15, 2018. This is straight from my book that's coming out this month called MAKE (http://makebook.io/) for $30. Don't worry, this book is only 1% of my income, so I'm not a bullshit artist telling you to buy my book. I am doing fine without it! Thanks! ABOUT ME I am Pieter Levels, the founder of Nomad List (https://nomadlist.com/), the biggest crowdsourced city database and digital nomads social network. I also founded Remote OK (http://remoteok.io/), the biggest remote jobs board in the world. After I was quickly going broke in 2014, I started building "12 startups in 12 months" which got a lot of attention and forced me to ship a new app every month. Most of those apps didn't become successful, but some did: Nomad List became a real startup with millions of monthly users, multiple acquisition offers, $25,000 to $40,000/month in revenue, while having a real cultural impact of getting tens of thousands of people to travel and work remotely. Remote OK started as a basic jobs board for remote workers, and grew out to now be the highest traffic generating remote careers platform with about $30,000 to $70,000/month revenue in job posts. My total revenue over all my projects together has now surpassed $100,000/month and is growing at 1.76x per year. I share this to make the point again: it's possible to bootstrap a company without venture capital and all the bullshit that comes with it. I also won Product Hunt's Maker of the Year in 2016 and 2018, won Product Hunt's Side Project of the Year in 2018, am the #1 most upvoted Product Hunt maker, got my apps multiple times to #1 on Hacker News and I was on the frontpage of Reddit twice (with Nomad List and Hoodmaps). I don't have the keys to success, so I can only tell you what worked for me. A few principles I hold is that I don't take external funding, I do everything myself, I mostly don't really hire, I automate a lot which means I have lots of robots working for me 24/7, I like transparency and I hate business bullshit. That means I share my revenue, share the problems I have and the successes when things do work. This presentation is pretty much that! EVENT PAGE:   / 1546232848746952   CREDITS 🎤 Host: Haren Tambi & Michael Craig @ http://dojobali.org 📷 Camera: Marc-Antoine Fonne 😃 Audience: Andrey Azimov, Clare Harrison, Petr Suska + more ⌨ Transcribing: http://rev.com Anna K. Portuguese (Brazil) subtitles by Eric Vieira @eric_vieira

 

https://readmake.com/#4-12

 

Thank you

The last years were a whirlwind of adventures while building all these products and being part of the startup ecosystem. I've met hundreds, maybe thousands of people while doing this. Writing this book is my final piece (for now 😛). And it wasn't possible without the help of a lot of people.

I'd like to thank every person who ever used my apps and websites, especially those who supported me financially by becoming a paying customer.

I'd like to thank all my followers on Twitter for supporting my work by giving me feedback, sharing it, and sticking with me through my ups and downs throughout this startup journey. Success sometimes makes you a dick (especially on Twitter!), and maybe I wasn't nice sometimes. So please forgive me and again, thank you.

I'd like to thank my family: my mom, my dad, and my brother Jeroen and Marijn for sticking with me and giving me true advice in times where it was hard to get objective feedback anywhere else.

I'd like to thank my girlfriend for repeatedly asking me "when are you going to finish that f*cking book?" for 2 years, but mostly believing in me when so many did not.

I'd like to thank my co-shipping friends: Marc from BetaList, Lowen, Andrey, Oskar, John from Ghost, AJ from Carrd, Courtland from Indiehackers, Daniel my Server Guy™, Xiufen Silver, Yury the Critic™, Jelmer (aka Dutch Levels), Amrith (aka the Shinbag), Vlasti, Suska, and Felix from Fastlane.

I'd also like to thank Patrick McKenzie (patio11), one of my biggest inspirations to start building stuff when I was reading his blogs on Hacker News years ago. Also Jon Yongfook who showed me you could build startups while nomading and not look like a broke backpacker while doing it but instead do it in style. And Derek Sivers who taught me to every day try to be warm, nice and humble. No matter how much you achieve. And Anthony from Hype Machine for always reaching out with advice.

Importantly I'd like to thank Jennifer de Walt for inspiring me with her 180 Websites in 180 Days project. If it wasn't for her, I wouldn't have made 12 Startups in 12 Months, wouldn't have made Nomad List and wouldn't be writing this book here. It's crazy how serendipity works.

I'd like to thank everyone in Work in Progress chat for keeping me productive and forcing me to finally finish this book (which took me too long).

I'd like to thank Product Hunt, and specifically Ryan Hoover and Andreas Klinger for always supporting me, giving great feedback and highlighting my startups repeatedly. And in a bigger way for creating this whole indie startup wave that I am benefiting from so much.

All of you, and you now reading this book, have changed my life forever. Thank you.

Why did I write a book?

I never wanted to write a book. I have to be honest to say I hardly read books myself. I think it takes a certain amount of hubris to put your thoughts in 200 pages and think you actually know something well enough that you should share it with people. But then all of you started buying it, so hey, let's do this!

I think it's stupid to read lots of books about doing something (in this case startups) and then believe you're actually learning something from it. Because most successful people I know learned mostly everything they know from practice. Just by doing things.

Books are also outdated by definition. The moment I write this sentence and you read it (weeks, months or years later), I might have already changed my mind.

Then there's the entire survivorship bias, it assumes that what worked for me will work for you. But it probably won't. Because time has already changed and I will never be able to put on to paper all the variables that have attributed to things than went successful for me. I really don't like to give people false promises. Which is what most other books do. No, this book won't make you successful. That's all up to you.

But I do want to write a book

Even with all these things stacked against writing a book.

I want to write a book, if only because I see so much bullshit going around in the world of startups and tech. The media is presenting startups in the wrong way. People think they need to build billion dollar companies. They need to fly to San Francisco and build a "network" and get $10 million dollar investment from old rich guys. They need to hire 10x power developers and work them for 100-hour work weeks while feeding them pizza and soda. It will be great, they said.

But it won't. It'll probably suck. And you probably won't get rich. Because the odds of a venture capital (VC) funded startup are by definition stacked against you. Only 10% or less exit and that doesn't even tell you if the founders make good money. There's giant company exits where the founders barely made money. That's why I'm writing this. To show you, you might be able to do it differently.

The indie way of building a startup

What's the alternative? How about this: do things yourself and build a nice side project, that then can maybe turn into a bigger project, that then maybe becomes a company that makes you enough money to quit your day job and stop working for the man. Enough money to build up good savings, that if you invest well, will give you a nice early retirement. Your own company that can give you a little more freedom in your daily life, so you can spend it with friends, your family, your pets or just doing the things you love. Which in the best case is actually building an app, project, startup or company you love to work at/on/for!

I want to make bootstrapping great (again) #MBGA

This way of building a company is called "bootstrapped". Which means you're self-funded. You use the resources you have to get started. The odds of building a successful bootstrapped business are way higher than building a venture funded billion dollar company. Because the goal of a bootstrapped business is much more reachable. You don't need to do a billion dollars in revenue. You're already there if you can pay yourself enough to live from. Any money that comes extra is even better! You'll probably have less stress, be happier and be therefore a better friend, lover, partner or parent. Just....relax.

The coolest thing about bootstrapping it is that it doesn't exclude "going big" later. Venture capital investors LOVE to invest in companies that already have proven revenue. And that's literally what a bootstrapped business is. You'll be miles further than the person next to you pitching with just a PowerPoint deck. When you go for millions of dollars of VC investment on day one, it means you do exclude building a healthy simple business. Your company is now strapped to a rocket and you need to go big or explode. That's why I think bootstrapping is the better way to build a business now.

I really, truly, honestly want to see the mainstream startup narrative change into one where bootstrapping, revenue and actual profit is "cool". Writing a book on it with a proven framework people can apply, may help accelerate this change.

There's a personal legacy aspect here: if I can have a small influence in changing this, it feels good as a person. It's nice to change things for the better. And if it doesn't, well, thousands of people paid me money for this book, so it's a nice backup for me in case I go bankrupt.

Why should you listen to me?

Because I went from really scrappy side project to profitable company with users a few times now. Most times it failed miserably, but a few times it worked out for me.

At time of writing, my website Remote OK just became the most visited remote jobs board in the world with 3 million monthly visits. Nomad List is near that amount too, and ushered in a new era of digital nomads and remote work from 2014 onward. They're both manually built by me, profitable with high margins (up to 95%), and highly automated. I was Product Hunt's Maker of the Year twice. I've launched my startups to Reddit's front page twice. I grew one of my projects into $100,000+/month revenue, then $200,000+/month revenue and together now to over $3,000,000/year, while blogging and tweeting about all the personal ups and (lots of) downs for the past years. I launched Rebase last year which went from $0 to $50,000/month in 30 days. I recently launched Avatar AI which went from $0 to $100,000 in 10 days! My projects together are now valued at anywhere from $10 million to $40 million depending on what the market would pay for it. And I did it mostly by myself. Most of my other projects failed (some miserably), but I was able to get an idea to success a few times.

There is a good chance that there is strong survivorship bias at work here though. Remember that. The people who try and fail don't write books how they failed. That means my entire perspective is probably biased and skewed. You've been warned.

This book is my entire brain dump

I've been getting thousands of questions the last few years. I think if I started answering them I'd simply not get to working on my own projects anymore. That's why this book is the easiest knowledge transfer from me to you.

Literally every single thing I learned in the last few years building bootstrapped startups is in this book. It's my entire brain dumped on paper. It can be messy but it's everything I know. I hope it'll be something like giving back to the community and people will use it as guide in becoming indie makers and ship products. I've seen the drafts of this book already applied in hundreds of launched startups (because people will usually send me a message), which is super awesome. I'd love to see more. Having some positive influence on people's lives is a lot more interesting to me than more revenue, at this point.

This book is continuously updated

I'll be working on this book just like any of my startups. It's a continuous project. I'll keep updating when I learn new things.

App, site, product, startup, business

You'll see these terms in the book used somewhat like synonyms. Because most of the theory in this book applies to all of these. Sites these days are like web apps, and apps are more like sites, together they are products and a few of these products make up a startup which in turn is a business. Generally, they're all the same thing.

You'll need persistence, and luck

You may need to try shipping 10 to 30 products for 1 to 3 years before you have anything that works. That's how this approach works. You build stuff and see what sticks. I don't know anybody who shipped one product and instantly became successful. It takes a long time to "get" it and even then it's a lot of luck and timing. If something doesn't seem to take off early on, it probably won't take off later, so make something new and try again.

As I, and this book practice radical honesty, there's a chance nothing you make will be successful. But by doing you'll have figured something new out, that might lead you to somewhere else, that will make you successful. Startups, and life, are about constantly pivoting when things don't work out. If you don't take action though, you can be sure nothing will ever happen. Stagnancy kills. So ship.

🚢 Always keep shipping.

Practice

I want you to learn from actually shipping a product. This book is just ideas that might be wrong or right, and biased, but your own personal practical experience will be the thing (if anything) making you successful. Not this book! This book is just me pushing you to go sit on the bicycle. Now learn to ride it yourself. Practice is everything. Get your own style. And most importantly, ship.

📕 This book

To avoid all those books with theories that are unproven, I felt on a very meta level, I wanted to write this book with the theory described in this book. To prove that if I could produce and sell this book in the ways described in this book, it'd somewhat prove the theories might work. So that's what I did.

Before even writing a single line on it I announced this book and opened it up for pre-orders:

The landing page was literally a Typeform telling that I wanted to write a book, but it didn't exist yet, and asking for $29.99 to support it.

The only thing people received after paying $29.99 immediately was an empty Workflowy list where they could write what the book should be about specifically. That gave me immediate feedback from customers what they wanted me to make. Just like a startup.

Thousands of people pre-ordered the book (quickly netting $50,000+ in revenue at $29.99 per pre-order) and there was thousands of items in the Workflowy list to write about. I went through it regularly and tried to re-order it to find patterns. I found I could divide up all questions people had in the different stages of startups. Ideas, building, launching, growing and monetizing. Everyone was at a different stage and needed different questions answered.

I then started writing the first chapter. I wanted to do this by "building in public" too. Or in this case, writing in public. I made a Google Docs text document and started writing.

But not before I started a live stream on Twitch of the writing process of course. I wanted to live stream most of the chapters. It helped me because, as you may know if you've ever written a book or thesis, the procrastination of writing can become incredible.

Every time I finished the draft of a chapter I sent it out to all the pre-order customers. And they could review it as a Google Doc again.

Only the final process of writing this book (where I'm at now), was done by myself. Collecting all the content, cleaning it up, rewriting it and making editorial decisions on what should be in it. But 90% of the process was out in the open.

And that's exactly how I have built and would build startups: launch early and build with/for your users.

💡 Idea

Introduction

This first chapter is about how to get ideas for a startup.

Solve your own problems

The most important thing is to find ideas from solving your own problems. You do that by looking at your own life and observing what your daily challenges are. Then you see if you could make those challenges easier using technology. If you solve your own problem, it's very realistic that there's many more people like you who would also love their problem solved. And that's pretty much what a business is. Solving lots of people's problems in return for money.

In startups, this business can be in the form of an application, a website or even only just a physical service tied together with some technology.

Your problem might just be everyone else's

My most successful project is Nomad List. It's a platform for remote workers and travelers to find places to go to and meet other people when they're there.

When I built the first version of Nomad List, I was traveling through Asia. I was living in Chiang Mai, Bangkok, and Bali. I knew these places were good for digital nomads, but I didn't know what other cities to visit. I'd go to Singapore, and discover it was nice but also very expensive. I'd go to Vietnam and realize wow it's really cheap here, but the internet is unusably slow. I was looking for cities that were cheap to live, had fast internet, and warm temperatures. I thought "Okay, maybe just make a list of cities with that data?". It was just a private spreadsheet first. I added about 25 cities' temperature, internet speed and cost of living. Then I wanted to share it, I tweeted the URL.

But something was off. When I looked back, someone had hacked my spreadsheet. There were now about 75 cities and it wasn't just temperature, internet speed and cost of living. There was safety, best coworking space and climate added as columns. Instead of sharing it as "read-only", I had accidentally clicked "editable by everyone". Suddenly there were hundreds of people adding data about their cities, and the cities they'd been to. After a month, thousands of people had added data about over 250 cities.

This is a good example because I just wanted to solve my own problem, and it turned out it was thousands of other people's problem too. Your own problems are nice because often they're quite niche level, meaning you'll have enough other people with the same problem to be your user, but not enough that some giant company has already done it.

You are the greatest expert at your own problems

Even if it's not always successful, the concept of solving your own problems is a great way to find ideas that might be viable. A lot of people don't do this. When you try to solve problems that aren't even yours, like somebody else's, you can do that but you are not an expert in the problem area.

For example, I could make a health care app which registers patients and their health situation, which diseases and ailments they have, and where they are in the hospital system. But I'm not a doctor. I've only been to a hospital when I was sick. I have zero expertise on health care. I don't know the problems doctors have.

I can look at the entire industry from an outside perspective and think: "Okay, we need to solve this problem. There's a lot of money and opportunity here". But I still don't know anything about it. I'm just not an expert in the problem space. And until I become a doctor, I probably will never be.

You want to find ideas from your own problems because you'll be an expert on them immediately.

How well do you need to know a problem to solve it?

Somebody asked me, "How well do I need to know a problem to make something for it? How much can I learn along the way?".

I think you need to know a lot about the problem you're trying to solve. Once you have traction and your website, app or startup works, you can learn from user feedback and data you collect then. But that's useful once you're already running. It won't help you find ideas that are suitable for you to execute. First-hand experience with the problem you're solving is best.

And not just at the start. When your company grows, and you stop becoming the target audience, you face a big risk of not understanding the customer anymore. A good example is in hip-hop, a rapper comes from a low-income ghetto, gets success rapping about that world, then gets rich from the success, loses the inspiration of that world since he/she now lives in a giant mansion and their career is over.

Personally, I saw this happen with myself. For awhile, I took a break from traveling as a digital nomad and the product suffered. Now that I'm back on the road, I see where my site sucks. For example, it doesn't work well when I visited smaller towns where there's hardly any nomad activity. So I lowered the membership price of Nomad List and started focusing on just getting more people in. As that's more important short-term than making money. I wouldn't have realized this by staying home.

Problems are always changing, as are markets, as are people. If you are your target market, that's perfect. You just evolve with it. The founder of Boosted Boards, an electric skateboard, said:

"We just wanted to make skateboards for ourselves and there was no real good electric ones. We built it for ourselves. We knew exactly how we wanted it to feel when driving. We knew what people wanted because we were the target market".

I'm starting to repeat myself, but that's because this is a repetitive theme with successful companies. And opposite: a repetitive theme with failing companies is founders who have no connection to, expertise on or passion for their industry.

Be more original, and your ideas will be original

There's an issue in itself with only solving your own problems. What if you're not as unique as you think? It takes only a slight glimpse at current startups ideas to see that everyone is making the same stuff.

Everybody's doing a to-do list app. Everybody's doing productivity apps. For a decade, people have been making apps to find your friends on a map. Everybody's doing some kind of photo sharing app. These are basic ideas that everyone has. And they're too obvious.

Everybody's doing them because everybody has the same problems. So how can you find problems that are actually unique and original? Well, become more unique and original yourself. I would have never built Nomad List if I didn't go traveling and working.

So, you need to do stuff that makes you explicitly very different. It will get you more unique ideas. That's super cool, because now you have two great attributes of an idea. It's not just unique, but it's also something you're an expert at since you've done it yourself. Even if you launch and get competitors later (like I did) because they see you're making money and it's a good market, you'll still be in a better position than them because you're real. You've done it. You're an expert in the problem you're solving.

I would be bad at making an app for doctors, but if I was a psychiatrist, I'd probably be able make a very good app for psychiatrists, since I'd know all about it. Part of the Lean Startup approach dictates "talk to customers to find problems". That's nice and all, but then you're still working from an outside perspective. I'd say, just focus on your own problems.

Also, stop reading books to develop yourself or get ideas. You won't get them from there. Or if you do, there's lots of other people reading the same book probably. Get ideas from your life experience. Get outside. Become original. Do crazy stuff that you're scared of. Jump off cliffs (do it safely). Ask people you like out (scary but nice). Walk into random office buildings. Jump fences (but don't storm the Capitol Hill, thanks). Crash hotel pools. Whatever makes you different. Don't be scared! Live.

The downside of solving only your own problems

There's a strong and somewhat valid criticism on the philosophy of solving only your own problems.

If you're a wealthy guy from a Western country, you're probably going to solve problems that make your already pretty good life better. You're not going to solve problems that women or people with other genders have, because you don't experience their problems. You're also probably not going to a developing country and solve the problematic garbage situation there. It's the privilege argument.

I get it. And I see the criticism there, but then, it's hard for anyone to solve a problem outside the context of their own subculture, city, country, continent, region, income class and gender, because they're not experts on it. And maybe that's not as bad as we think. If we can democratize access to computers and the internet (as we're doing now), people anywhere can focus on solving THEIR own problems and reap the financial (and other) rewards from doing that. And isn't that much better than having a white guy do that and reap the rewards?

Always start from the problem, not the solution

A lot of companies start not from the problem but from the solution. This is one of the biggest mistakes you can make. Technology needs to solve a problem. If you make a solution for a problem that doesn't exist, it might look sexy technologically, but it won't get users.

When new technology becomes available people want to use it to build something. A great example is the endless amount of apps that have appeared since smartphones got GPS chips a decade ago. The first thought is, okay, let's use this to track each other. So you make a map with friends on it and where they are. This has been tried over and over and it's still a pretty terrible idea. I don't have a strong curiosity to know where my friends are and I don't necessarily want them to know where I am (due to privacy). The problem doesn't exist. When I meet up with friends, we simply say a place we're meeting up and we can find each other.

Now a good example where this technology is used to solve a problem would be Tinder. It does use your GPS location, to find people around you to date. That works because you don't want to match with people on the other side of the world. It solves a problem and the solution is enabled by available technology. The problem should always be first, not the technology, not the solution.

To get big, you have to start small

Niches are specific market segments that are shallow enough to easily access, with not many players in there. Niches are a great start because they're usually too small in economic value for big companies to attend to. They're also the perfect size to market a new company towards.

Niches go against the ridiculous "go big or go home" attitude that the rise of startups in mainstream media pushed from 2006 onward. But that attitude isn't realistic. Because most big companies started very small. If you start big from day one, it's the wrong way to go about it. People don't like niches because they're too small for people's ego's.

But niches are much more profitable than you'd think. If you have "just" 1,000 people paying you $83.33/month, that's $1,000,000 in revenue in one year!

How to make $1,000,000
Make a	$5,000 product for	200 people
Make a	$2,000 product for	500 people
Make a	$1,000 product for	1,000 people
Make a	$200 product for	5,000 people
Make a	$100 product for	10,000 people
Make a	$10 product for	100,000 people

How to make $1,000,000 w/ subscriptions
500 people pay you	$167/month for 1 year
1,000 people pay you	$83/month for 1 year
2,000 people pay you	$42/month for 1 year
5,000 people pay you	$17/month for 1 year
10,000 people pay you	$9/month for 1 year

Start with a micro niche

Let's say you want to make booking software for hairdressers. That could be a niche. But how many hairdressers are there? Probably millions worldwide. Why not go even more niche? Booking software for hairdressers that focus on African hair. Now you're talking tens of thousands maybe. That's a good start. Let's say you captured only 10% of those 10,000+ hairdressers that focus on African hair, that could be 1,000 customers paying that $83/month making you a million-dollar bootstrapped company!

From micro niche to multi-niche

If you're at a party and someone asks you what you do and you answer you make booking software for African hairdressers, you might think it's too basic, i.e. you're not "changing the world" with this. But you shouldn't. Because first of all, you're probably making good money off those 10,000 hairdressers paying $100/y (that's $1M/y in revenue already!). And if you've validated your startup in that niche, you can expand to other niches. What about Asian hair? White people hair? Step by step you move closer to the entire booking for hairdressers market. Why do it step by step? Because you can easily go smaller again if you fail. And try to expand in another direction. It's like a lightning shock in slow motion, it tries to find the path of least resistance. Your company should be doing the same thing.

From multi-niche to adjacent markets

Now let's say you have the entire booking for hairdressers market, what about booking for nail salons? And tattoo shops? Now you're doing restaurants. Now what else do all the shops need? A point-of-service payment platform. Okay you have all these shops as customers already, so you can easily sell this new service to them too (and best of all test it on them first). You then scale up frm multiple niches to adjacent markets.

From adjacent markets to becoming a platform

With the experience from payments for physical shops, you move to virtual payments too. With lots of luck, you'll be one of the biggest payment gateways in the world. You'll go into ecommerce with virtual storefronts for the physical shops of your customers.

You just became big by starting small!

See what happened here? You became big by starting small. Most people do the opposite and crash and burn. They want to build that giant payment platform that will change everything. But hardly anybody started with that. Facebook was a Hot Or Not app by Marc Zuckerberg. Apple was a personal computer build kit for amateur hackers. Microsoft was a tiny software agency that re-sold MS-DOS from another developer to IBM. Google was a small academic experiment to search Stanford University's local intranet. Get it?

Stop. Thinking. Big.

Think small first! You'll be big at the end!

Your idea does not have to be earth-shattering

I don't think your idea should be earth- shattering. If you look at most big startups, their first idea was not earth- shattering at all, most of them. Think Uber. They started as an app where you can simply call a taxi. Right? Then it grew into an entire transport solution. The long goal is self-driving cars, that transport everything and to replace the entire transport and delivery industry.

All that started with a taxi hailing app. Your first idea does not have to be (and probably should not be) earth-shattering.

You start with something small. Don't think too big. Then slowly, you can get to the big part by extrapolating, scaling your idea to a bigger market, from a niche market, and to a bigger more abstract idea.

With Nomad List, I started with a list of cities with cost of living and internet speeds. Then I scaled that up to a social platform for digital nomads. Now the long-term goal is an entire internet platform for the future of remote work. That means more tools for nomads, remote workers and businesses that embrace this future. That all started with a database of cities, that's not earth-shattering at all.

The more I talk with people in the startup world and they tell me like, "This idea is going to change the world. It's going to be a billion dollar company." Those are usually the ones that fail really, really bad. The ones that go really well, and I know from seeing friends around me, are the ones that are people who are really modest and they just say, "Ah we just want to fix a small thing. Then okay we fix it. Okay. What's next? What are we going to do next." They do probably have a long-term vision, but focus on the small stuff every step of the way. Because that's how you get big: by focusing on small steps. If you can't even do the small steps right, how are you going to get to the big part? Right?

Don't focus on the idea that is earth-shattering. Just start with something basic. Virtual reality is an industry that will be earth-shattering, but you don't have to have an idea that's earth-shattering. You can start with a basic, little virtual reality game/app (like I'm doing now) and slowly add functionality until maybe it becomes like the next virtual social reality world where we're going to live our lives in.

You don't know what you're going to end up with. That's another point. You need constant feedback from your users in the markets to see what people want and what people use and whatnot. You can't just think of that. You can't think big immediately. You have to start small.

Create a list of ideas and keep track of them

A good start if you're looking for ideas is to keep track of any you might get. How you keep track of your ideas is up to you. I now use Workflowy and previously used Trello for it. I have a few different lists. The first is for "Concepts", that's rough ideas. Then if one of the ideas looks good, I move it to the "Promising" list. If I actually start executing them I put them in the "Building" list. Then if it's done I have a "Success" or "Failure" list. When it's a failure, I usually also write inside the card why it failed in a post-mortem that's one sentence long.

The first list of basic ideas has zero limits in how weird or crazy the ideas can be. This is on purpose. There shouldn't be any judgment on your first basic creative premise. It can evolve into something more practical later.

The thing with ideas is, at least with me, that they keep coming back in my brain. I'll get a basic hunch, then weeks later it comes back, and then months later it'll start to manifest in my mind. Then sometimes even 2 years later I'll finally start executing it. This is great because your mind is like a rice cooker for ideas. They need to get ready before you can put them out and build them.

This list of ideas doesn't have to be physical or virtual, it can also just be in your mind if that works for you. As long as you keep going back to ideas and see if they have evolved to become worthy of actual execution.

Should you make ideas alone or in a group?

I think collaborations can be very dangerous. Because if you work with somebody else in a team, there's a big tendency of groupthink, where everyone starts hyping each other on the value of the idea. The prototype might only get mild validation from paying users, but you're working with this group and you're already so crazy about it that it doesn't really matter what users pay/do/say. That's very bad. It should only be about the users.

I've been in these rooms, I've seen it happen. "I"m telling you Joe, we've got something really good here". No, we don't care. It should be only about customers. You see a lot of startups go wrong because they have this group think in the beginning and it's actually not rational thinking. You're more rational on your own. Obviously, collaborations can work with idea generation too, but I think the most important part of idea generation is getting ideas yourself, then talking to people, customers, users to evolve them. Not talking to your teammates how great your team's idea is.

The worst is to be with people that just confirm what you already think. The best is to test your ideas as quickly as possible. Even asking other people for advice is kind of bullshit. You can't ask "will this idea work". You need to ask the market by building it! Nobody knows until you launch!

Don't be afraid to share your ideas

The most elementary mistake people still make is not sharing their ideas. No, people won't steal your idea if they like it. And even if they do, they probably can't execute it as well as you. And even if they do, you're not a snowflake! There's thousands or even millions of people with the same ideas as you. Stop thinking you're so special! Ideas are a dime a dozen. Everything is about how you execute.

Idea

x

Execution

=

Business

Bad idea	=	0
Good idea	=	10
Great idea	=	20

No execution	=	$0
Good execution	=	$100,000
Great execution	=	$1,000,0000

"To me, ideas are worth nothing unless executed. They are just a multiplier. Execution is worth millions. To make a business, you need to multiply the two. The most brilliant idea, with no execution, is worth $20. The most brilliant idea takes great execution to be worth $20,000,000."

— Derek Sivers in his famous essay "Ideas are just a multiplier of execution" (2005)

You shouldn't be scared of sharing your idea because execution gives the idea its details and specifics. That means 10 people with the same idea will execute it in 10 completely different ways.

The benefit of being able to share your ideas is that you'll be discussing them with everyone. Potential customers, vendors, suppliers, whoever. Everyone will have some input on it which you may or may not use as feedback. Again, the market remains the most important feedback though.

Not sharing your idea is stupid because it'll stay only in your head. You for sure won't be objective at judging it since you have something called "optimism bias" which is "the tendency of individuals to underestimate the likelihood they will experience adverse events", e.g. you think it'll definitely be very successful.

It doesn't matter if people say "that idea will never work" because they're not the validation. The user paying/using it is the validation, not other people judging your idea! The point of sharing your idea is thus not to get people loving it or hating it. The point is that you get your brain working outside of its comfort zone (of talking to itself) and you'll evolve your idea. You'll come up with adaptations of your idea, or entirely new ideas by talking about it.

Conclusion

To get ideas, try to find problems in your daily life. You're the foremost expert at problems you have, more than anyone else who doesn't have them. If you keep coming up with the same ideas as everyone else: try to make yourself a more original person by actively experiencing different things. Don't shy away from taboos and fringe ideas, that just mean you're ahead of the curve, they might become the next big thing. Don't think big, start thinking small first, then take it one step at a time, you'll become big by starting small. To avoid groupthink and drama: work alone, especially early on. Share your ideas freely to get other people's input on them. Log every idea you have, filter them, and see which ones you can execute upon.

Resources mentioned

• Workflowy
• Trello
• Stripe
• Zapier
• Intercom
• Olark
• Typeform

Your homework

• Spend the next 7 days making a list of problems you have in your daily life, they can be small or big, try to find 3 ideas per day, so that you have at least 21 at the end of this week.

🛠 Build

Introduction

You made it to the second chapter. We'll now discuss how to build your idea.

In the previous chapter we looked at how to find ideas for your product. To avoid getting stuck in an infinite loop of brainstorm and bullshit, you want to start building as soon as possible. The faster you get it out, the faster you'll see if people want to use it, how they use it and what other features they want to see you build. Without shipping, it's difficult to get any idea of what they want. There are obvious exceptions here: Apple hardly uses any focus groups or user testing, they choose to ship the very best (according to them). That's fine, but you're not Apple (yet).

Build fast and minimal

While a decade ago development time was long and took lots of planning to get right, today we can go from idea to basic product in a matter of days.

We have cheap and easy to set up servers (virtual private servers or VPS, like Linode and Digital Ocean), and platforms as a service (PaaS, like Heroku) that take out all the difficulty of setting up your own server. Server operating systems like Ubuntu have become relatively simple to set up with tutorials readily being available online. The web server software itself has become fast and simple too: NGINX allows us to set up a basic default server that doesn't need much further configuration. Languages like Ruby, JavaScript, PHP and their frameworks like Ruby on Rails, Meteor, Laravel make it easy to build products by skipping the ground work.

It's fine if you don't recognize a lot of the terms in the previous paragraph. This isn't a technical book. And the tools with which you make your product don't really matter in the beginning (and not even that much later either).

My point is, the speed of the development can be very fast now. And the zeitgeist of our time is transient too. Everything moves fast now, and where in the past people would use an app for days or weeks, now you literally have seconds to make an impact, or they close/uninstall it. So you have to move fast to stay ahead. Another attribute of our zeitgeist is minimalism. Users finally accept minimal interfaces and minimal functionality, as long as an app does what it says well. There are single-purpose apps now that just do one small thing very well. Many of them have been quite successful.

Downsides of fast development

There are downsides to this culture of fast development. There are products these days which are still littered with bugs when shipped. They might not work well on all mobile devices. They're not tested. There's products that are launched and work great in the first week, but then their developers stop maintaining them and they break after a few months. The remaining users get annoyed when the app stops working. With development being fast, rough and dirty, so are the results.

The other downside is you don't have the time for sophistication and details. Code has a higher potential to become an epic mess of spaghetti because there's less architectural planning involved. But then again, you can always rewrite code right? At least you've shipped. Users don't care how your code looks.

Your enemy is perfection

The reasons you should launch fast are to avoid inaction due to perfection. You should start avoiding striving for perfection now and maybe later too. This applies to all phases of doing a startup (and maybe even life), but especially the start. Perfectionism is detrimental because 9 out of 10 times it doesn't make things better but just creates inaction. You'll have 50 meetings, 100 iterations of an idea or feature, just to get it right, when actually you should have just gotten it out of the door immediately and let people use it (and learned from them using it!). Perfectionism is necessary in smaller details of your service or startup, but not in the entire thing because then it will simply paralyze you with inaction and fear that what you do is not perfect. Nothing is perfect at the start. Things become perfect through lengthy iterations!

If you're in the early stages of a company, you want to get out stuff as fast as possible. Actually, overall I think in the entire stage, it will be useful to do that because users love new features. They love to test new stuff. They're actually pretty okay getting into bugs. They know development is difficult these days. I mean Gmail was in Beta for a decade. People are fine with errors, as long as they can use something new and as long as the errors get fixed, and if they have some way to tell you the feedback about the errors, for example. I think getting stuff out the door is the number one priority.

Avoiding perfectionism is a skill you have to develop. You need to learn to be fine with everything being not fine. Not everything will be perfect and high quality. Maybe your website will have the wrong images, the wrong background colors and the logo color doesn't match the branding text in the rest of the page. Is that important? Really? It's okay for a day. It needs to be fixed at some point, but it's not a priority. The product works. Prioritize perfectionism. Perfect what needs to be perfected now. The stuff that's low priority, don't put too much effort in it to perfect it.

You'll always have time to perfect stuff later. You can always iterate and develop it to be great later. Why not perfect it step by step? Make small improvements.

There's a limit to this though. Don't make shitty products. With minimum viable products there's been a rise of people shipping products that look bad and hardly work. A first prototype should function really well. It's fine if there's some bugs on the side, but the core functionality should be operational. It should look at least OK, otherwise you simply turn people away. Minimum needs to be minimum good.

How viable should a minimum viable product (MVP) be?

The bad MVPs we're seeing recently are creating a counter movement against the lean product development trend. And that's understandable. A lean or minimum viable product doesn't mean it can be shit! It has to actually function, users have to be able to use it. Bugs are fine, but users should be able to report them instantly (like with a feedback chat box pop up). You'll also have to fix bugs fast or people will get annoyed (and you'll just grow more and more bugs). Making a minimum viable product means it has to be viable, it's not an excuse to be lazy and make something half-assed. So it's all about balance. Make something great that functions and it can be minimal. But make sure it works!

Build yourself or outsource

Many people ask me if they should build their product themselves, outsource it to other people or hire full-time employees to build it for them.

I have a pretty extreme opinion about this that goes against the grain of what most say. But I think I'm right because times are changing.

DIY vs. people who hire others to do it for them

I think you can get quite far by letting other people develop your product for you, but the problem is that in the long term you won't be able to have the same speed as a product maker with development skills.

To give you an example: my day usually starts with waking up, showering, having some coffee, seeing what bug on one of my sites is emailed/tweeted/shared with me today (someone sends me a bug report almost every day), and I'll see if I can fix it immediately. Then I'll see other stuff on my site that I don't like, and I'll just change it on the fly. All of this usually takes a few minutes. Those are just small tweaks every day, but over a year that's like 300 to 1,000 small tweaks which add up.

Now imagine if you outsource all of this, and you have to ask 1,000 times for a developer to tweak this and that. For me, a small tweak or bug fix will take just a few minutes because I can do it myself. But for you, each tweak takes a message to your developer, who then has to be working that day (and awake!) to get it fixed. He might have to do a meeting about it with his team. So it might take a few hours, or days, or weeks.

Now imagine if we have the same site and you and me are competing. In the time you've sent a bunch of emails to your developers, I've already pushed 5 bug fixes and added 2 new features to my app. Who's going to win here? Who's faster? Not you!

Now think about your users. They're now stuck with a bug for 3 days because your developer is hiking up a mountain in Peru for holiday. I fixed that bug while having my coffee in the morning in 5 minutes. What will your users like more? Your broken app or my working one?

It's not all roses though. Doing everything yourself in the long-term probably doesn't work. If you've proven a business model, it's probably smart to keep repeating it (by scaling it up), getting people to work FOR you, with you managing the operations instead of micromanaging and fixing tiny bugs. But that's not what this book is about. We're talking about the beginning. In that case, DIY always tops outsourcing for me.

DIY vs. big teams with VC money

I've seen countless real life examples of VC-funded companies spending loads on building giant development and design teams, or paying the same money to outsourced development and design agencies. There's lots of exceptions where it went right, but mostly in the beginning this just slows you down terribly.

There's been about 5 big direct Nomad List competitors come and go now that have been VC-funded from 1 to 10 million dollars in funding with teams from 10 to 30 people that made the same site as me. But they all didn't go anywhere.

While working alone in my underwear on the side of my hotel bed with my MacBook and my coffee, I was able to outcompete million-dollar VC-funded teams of 30+ people in an office in San Francisco with Aeron chairs, oakwood meeting desks, $20,000 espresso machines, bean bags and ping-pong tables.

That's a really cool thing about the time we live in. It's a pretty fair race. You just need to make a better product than other people and it gets rewarded by people using it.

When starting up, you don't need a team if you have the skills yourself. You don't need startup capital if you have the skills yourself. And getting the skills yourself isn't that hard if you can search every question on Google. And in my opinion, having those skills sets you apart.

You don't even need to be great at it. I'm not great at programming or design. I'm pretty average. But because I can do it all well enough, I have an advantage over many people, teams and companies who are specialized.

My gripe with venture capital in terms of building products

My social media outrage might make you think differently, but I don't hate venture capital. It has its function and place. But I don't like to see (other people's) money wasted on bullshit. And there's plenty of VC money funding bullshit. The costs of building a startup (especially, especially in the beginning) are almost $0 now. That is, if you use your own current skills.

There's a problem with the current narrative for how you're supposed to build a startup:

• Get VC money from day one
• Hire too many developers, designers
• Rent an expensive office
• Have your team build something
• Buy an espresso machine
• Do team-building retreats
• Buy startup goodies like t-shirts and hats with your logo
• Get drunk in a jacuzzi to celebrate raising more money
• Oops, the product didn't get traction
• Sorry VC, we shut it down
• Bye money!

The more sustainable way to build a startup:

• Build something yourself
• See if it works
• No, build something else
• See if it works
• No, build another thing
• See if it works
• It works!
• Let's see if I can monetize it
• I can hire some people now with the money I'm making with it
• Now I have a team of a few people
• If we want, we can rent an office, or just save money and stay remote
• The business model seems to be proven because every time I spend $1 more, I get $1.50 in revenue, thus it's scalable.
• This means, if I get more money, I can spend more and get more profit theoretically
• Maybe we can borrow or get some angel investor or VC to fund our expansion in return for giving away some of our ownership, or use our cash flow for it
• We got more money now, we spend it on the right things, and now we're making even more profit, it worked!
• Now the product is really cool, people love it, and we're making lots of money, mission accomplished
• Let's see if I can sell the product because I want to do other stuff with my life (build a family, start a farm, raise kids)
• Okay, I sold it for $500,000 to $10,000,000, now I have financial independence in return for a few years of hard work and my investors are happy too!

This is relevant because venture capital money can destroy the build process before it's even begun. If approached wrong, raising money means you can skip the actual product validation (if people want the product) and finding a business model (because you don't need money to survive, you have funding). It lets people spend lots of money without having to see any (positive) results for it for a long time. That causes people and companies to be jaded. It's not natural for humans. The natural tension of having to survive is healthy and it makes people act in superhuman ways.

There's always the story of the son or daughter of rich parents who could never find a job until their parents cut all spending on them and suddenly they found a job (because they HAD to get a job to survive). I think the same applies to companies. If you don't need to find a business model (to survive), you're not really going to prioritize looking for it either.

Bootstrapping vs. venture capital

Bootstrapping has become an advantage. You keep your costs low, naturally. You get zero of the bullshit attached with VC money. You maintain full ownership over your product and its roadmap (where you want to go with it). You maintain full ownership over the equity so that when you sell it later, you'll get lots of money (instead of just a diluted 5% because VCs took the rest).

And in our times you don't really need a lot of money to build something yourself. A simple web server is $5/month. A code editor like VSCode or Sublime Text is free. To make iOS apps, XCode is free. An Apple developer license is $100/year. Not a lot compared to the money you can make back from it if you can get people to use your product and pay you hard dollars for it.

Bootstrapping has become a very viable option for most software-based startup ideas. Whereas, venture capital has become tedious to get (schedule 6 months of meetings), limits your freedom (grow crazy big or die) and not really necessary at all. Did I mention how much less stressful bootstrapping is, yet? No, well it is!

The importance of keeping costs down

In the early stages of any project that's not funded, keeping your costs down is your biggest priority. And if you use your own skills to make the basics, that's a lot of costs saved. Developers these days are crazy expensive, due to high demand for them. Most dev's go for $50 to $250/hour. Just the MVP of any small app will already cost roughly 100 hours of work. So there you go, that's $5,000 to $25,000. A fully functioning app will cost thousands of hours, from $50,000 and up.

That's a lot of money if you don't have a lot of money.

So, if you have access to a big money pile, then why not, go and hire some people to build it. But you'll still be competing with a lot of DIY-ers that don't have that cost, and you'll want to get your costs back at some point in the form of revenue. If your development costs are so much higher than the rest, you'll also need to make a lot more money than the rest. Possible, but hard. Especially in the beginning.

Now, the worst you can do is contact a developer and ask them to work for free in return for a 50% share of profit, while you get the other 50% because you came up with "the idea". It's become a startup trope and it's ridiculous. The market value of an idea without execution is $0. So either you get REAL skills (an MBA != skills), or get money to pay developers. Paying with future equity is ridiculous, it's like paying with a $5 lottery ticket. Don't make a joke out of yourself! Nobody works for free anymore. You have to understand, as a developer you can now make $150,000/year as a starting salary in San Francisco. Do you really think anyone cares about your startup idea of a random person such as yourself? Not unless you have something to bring to the table, like money or skills. Some people used to add connections to that list, but I don't really believe networking is important in this age anymore. What's important is the product and to make it you need money or skills.

To build, should you learn to code?

Yes, I'd recommend you learn it. It's only getting easier now. Learning to code seems steep for newbies. But people approach it wrong. You can probably ride a bicycle, right? When you started "learning to ride a bicycle" did you think you'd be Lance Armstrong? No. And you probably aren't. You can just ride it, but you're not competing in world championships.

It's the same with learning to code. It doesn't mean you have to be great, or even good at it. Just know some bits so you can throw stuff together. When I code, every day I have to Google how to do stuff I don't know. Coding is continuous learning. You can ask any programmer and they'll answer the same. The good thing is, there's so much information on the internet nowadays. Almost every problem you face, someone else probably had before you.

If you're looking for ways to "learn to code", I'd say don't go for courses, bootcamps or mentors. They usually cost a lot of money and they don't teach you the core of coding: figuring it out yourself. That's the biggest skill. Fiddling for hours to days to get something working. Not giving up and keep trying. And then suddenly: EUREKA!

If you want to learn to code, my advice is: try to build your idea with HTML and CSS and some JavaScript and see how far you get. Just Google every single thing you don't know. Start with "how to make a HTML page". Then "how to make text colored in HTML". Then "how to make a button in HTML". Etc. Keep searching. You'd be surprised how far you get. This is how I (and many others) have learnt to code. Figure it out for yourself.

If you really don't want to learn to code, read on as I'll discuss how to build a basic app without a single line of code later in this chapter.

Tools

Which tools should you use to build?

I'm a strong believer that right now you should use whatever tool works best for you. What tool do you already know? You've already worked with Ruby once? Was it fun? Use that. You've already worked with PHP? Then use that.

What you should definitely NOT do is listen to programming hipsters on the internet telling you which language is best.

Here's a little secret: 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.

So use whatever is easiest for you to learn or work with. And then switch whenever you feel you've outgrown a language. But honestly, unless you're programming spaceships, it's pretty hard to outgrow a language. They're all based on the same principles of computing. You can build anything with most languages really.

• Facebook was built on PHP
• Twitter on Ruby
• Google on Java
• Reddit on Python
• Hacker News on Arc

The thing is, you're not building for the enterprise here. You're building a first product that might grow into something bigger and then turn into a startup company. You can always switch. Twitter switched from Ruby to Java after they kept going down. Twitter still exists. When Facebook became popular, it became overloaded with users, so they wrote their own engine (called HipHop) to speed up PHP. And they started writing critical parts that needed more speed in other languages.

The point is, it didn't stop them from being successful, so surely it won't matter for you.

What if you don't code? I'd recommend you to learn to code of course. But for you, I've written an entire part on how to build without code, further down in this chapter.

My "light" stack

What I use personally grew out of my limitations. I wasn't educated in Computer Science or even programming and I simply used what I knew a little bit about. I didn't listen to everyone telling me what hip new framework (anything.JS etc.) or language (Ruby etc.) to program. I knew some PHP from making some WordPress sites before. And years before that I making my websites interactive with Perl, and it looked pretty similar.

Now the point is, don't go learn PHP. But use what you already know and see how far you get with it. And move to the next language or framework if you're starting to reach its limitations (which seems very hard with most modern languages).

The basic lite stack is a front-end (client) that is built with HTML, CSS and JavaScript. You then use the JavaScript to communicate with the server by making a web request. That request is received by your backend (server). This backend can run anything. I use PHP, but nowadays you can also run JavaScript on the server (with Express or Node.JS for example). You separate the backend (server) from the front-end (client) for security reasons because you don't want to let your entire user database be viewable by one user, right? The backend code connects to your database (SQLite, MySQL or PostgreSQL are great).

SQLite specifically is great because it doesn't require you to install a lot, and when you make a database, it's just a file. It's very transportable. You can literally copy the database file from and to your server. There's misconceptions about SQLite that it'd be slow or not scalable enough. That's bullshit. In many cases, SQLite is now faster than the filesystem (!) itself.

There's a giant trend now to merge the client and server-side programming with frameworks like Meteor, React, Vue etc. And I support it. But at the time of writing this book, it simply is too convoluted and complicated for beginner programmers. It's a rabbit hole really. We don't know where it'll go really: will we get more people using basic light stacks like this one (which still separate front-end and backend) or will people all move to frameworks like React.JS? Just because a technology is newer, doesn't mean it's better though. My guess is we will probably merge front and back end at some point. But at time of writing this book, things are changing too fast to use it for me.

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. PHP is over 2 decades old and JavaScript similar.

Does it matter what stack you use? Again, not really. Just use whatever works for you. In my case, that's this light stack. I keep it simple. Most companies will eventually build their own framework over time, and in a way that's what I did. But it was never my plan. You just streamline functionality that you keep repeating. Remember, you can always switch the stack later. It'll hurt but it's completely possible.

Why are people so obsessed with tools?

There's a recent trend of people becoming viciously obsessed with discussing tooling. What language do you, should you and will you use? Why all these tool discussions when it's not that important for shipping a product? I think people are obsessed with tools because it feels like they're actually doing something productive. Because when they figure out what tools they should use, they'll go learn that tool (or language) and build their product right?

That's the idea, but it's stupid because it never happens. They get stuck in this endless research. They'll learn a new language, then switch to the other one. Because this new language, tool or framework "may be a better fit" for the product, that is the product they still have to build and ship. Not any of these people ever finished what they wanted to make. And the problem is, every week a new framework shows up that promises to make your app or its development even faster and easier.

All of this stuff simply takes away from your goal, which is shipping a product and selling it to users and getting revenue from it. Who has this problem more than anybody? Software engineers. It helps to be a bit business-ey here, because business people always care most about revenue. And if a profitable company is your goal, you should too make that your first priority! Not the tools.

What about the people that finished and shipped? They mostly never cared in the first place about tools. They weren't discussing which tool to use. They just made something with whatever tool seemed good enough. And they switched it whenever their tool limited them and they needed something else. They're "toolset ambiguous".

So, stop asking that question "what do you use to make that?" or "how did you make that?". It's an inherently stupid question. The question should be "why did you make that?". The philosophy behind something is way more important than how they made it. You can copy their tools, but you'll never be able to copy their WHY (which is what makes people and their products great).

How do you evaluate if a new tool is useful for you?

There has never been a time during which there has been as much innovation in programming languages as now (except in the post-war 20th century with the rise of computing itself.)

The center of programming is on the web now. There's new languages popping up every month and new frameworks every week. This makes it hard (especially for newbies) to judge what language or framework to invest time in to learn. You learn a new language, but it might already be passé by the time you finally understand it.

My approach is that I only learn what I directly need now. Let's say I'm building a new app where I need to make beautiful charts in HTML quickly. I'll try it on my own first, but if it's too much work, I'll just Google "charts in JavaScript":

I'll find D3.js, the dominant visualization framework for JavaScript and learn some basic stuff to build a chart.

The thing is, I only learn what I need when I need it. Instead of spending months on learning an ENTIRE language, framework or tool. I just learn the bit that I need now. This is a much faster and leaner approach which will save you time and make you more productive. And actually ship your product.

I don't have so much of an inherent interest in programming that I'll go and learn stuff just for fun. I know many people do. If your goal is to ship, that might be a disadvantage, because you'll learn lots of stuff you don't necessarily need. And you'll be playing around with tools more than you'll be finishing your product.

Native vs. web

Web

A web app is a website that has the functionality that makes it an application. It can look the same as a native app, except that you access it through a web browser like Safari or Chrome (on your phone). You'll probably build it with HTML, CSS and JavaScript.

Native

A native app means that you program it in the language native to the device you use. And it'll be an actual app installed on the device. For an iPhone that means you'll build it for iOS and it'll use Objective-C or the new simpler language Swift. That's usually what people mean when they say "mobile apps".

User experience and development

In general, a native app's user experience feels faster than a web app. Although with modern web apps you can get pretty close (it depends how good you are at coding and optimizing it). In general, development of web apps is faster, but the user experience is slower, whereas development of mobile apps is slower, but the user experience is faster. A native app has the disadvantage that users have to actually install your app. That takes another user action. Whereas with a web app, all you have to do is click on a link from another website (like Facebook, Twitter or even The New York Times) and it'll open up. A web app is nothing more than just a sophisticated website that is made to look like an application.

Updating native apps vs. web apps

When you make a change to a native app, you need to deploy it to Apple and Android's app stores. It needs to be reviewed by their staff and it might take days before your update is pushed into the store and weeks until all users download and update it. Instead, updating a web app literally means uploading the new version to your server, and every user that loads it will immediately load the new version. That means instant updates.

Hybrid web + native apps

There's famous hybrid apps that are half native and half website. Until recently, Uber used to be a hybrid. This meant it could launch special features on the map (like for Valentine's day, cars in the shape of hearts, as this was just some HTML they changed), without having to deploy an update to the app stores.

A more recent example of somewhat hybrid apps is React Native (which probably is outdated by the time of reading this), which is a framework that lets you write platform-independent code (for both iOS and Android) in a HTML, CSS and JS-like style to make native apps.

What are people using most?

There's some data that suggests people on mobile devices spend more time using native apps than web. That's probably true. But they'll spend it in major apps like Facebook, Instagram, YouTube, Twitter, WhatsApp and Messenger (remove from this list depending on whatever is popular in the time of reading this book).

These are core apps though. They're giant. You probably won't be able (or want) to compete with these apps. How about using them as your platform?

A future where your web app lives inside other native apps

What I mean sounds crazy but it's where I see this going. People will use your web app INSIDE these apps. What happens if you send a link to somebody on WhatsApp? They see a URL, they tap it, it opens INSIDE WhatsApp's web browser. It's a fully functional browser and your web app can run inside it. A web container inside some big company's native app is the real future platform for your web apps I think. Design for that use case. It's intrinsically viral as people will send your website's URL around and open it from there. They won't have to install anything.

The web and native will merge in the future

I believe that web apps and mobile apps are converging. You see web apps get more and more powerful and getting access to more functionality of the device that was usually limited to mobile apps (for example the iPhone's gyroscope is now accessible through web). Other examples are how recently (2016), iPhone's browser doesn't show entire URLs anymore, like "http://nomadlist.com/amsterdam-netherlands", but instead shows the name of the site in the URL bar "nomadlist.com". That's obviously pointing towards seeing the web more as apps. In the long term, there are a few obstacles to overcome for the two to converge. Honestly though, it's impossible to predict. Five years ago, I would have thought by now everything would be, but we still have users both on the web and inside native apps.

Learn both

If you have spare time, learn to do both web and native app development. It's a remarkable (and sought after) skill to be able to build both web apps and native apps. And of course, hybrid ones!

What are you able to build now?

This book is about getting something out as soon as possible. Therefore, you should choose the platform where you already have some skills. This way you can get something out as fast as possible. For most people, and definitely for me, that'll always be web. Programming (and shipping) native apps to mobile devices and getting them into app stores is more work than just building a website, uploading it to a server and hooking it up to a domain name. Do what's fastest for you.

Other people will say I'm wrong there, and you should base it on how users will use your app. That's a good point. But I don't want to see you get stuck learning Objective-C and Swift to get an iPhone app out, or paying a mobile developer $25,000 to build it for you.

Remember: you can ALWAYS go native later. If people use your site already, you can bug them to install your native app later. This is annoying but it's possible. No platform choice has to be permanent.

Building with constraints

I'll now discuss how to build stuff if you're constrained. Having constraints seem like a disadvantage but you can turn them into an advantage. So many people look at the negatives in their current position, but in fact, most of these can be considered a positive advantage.

No money/investment

As mentioned previously, bootstrapping has become an advantage. You keep your costs low naturally. You get 0 of the bullshit attached with VC money. You maintain full ownership over your product and its roadmap (where you want to go with it). You maintain full ownership over the equity so that when you sell it later, you'll get lots of money (instead of just a diluted 5% because VCs took the rest).

And in our times you don't really need a lot of money to build something yourself. A simple web server is $5/m. A code editor like Sublime Text is $80. To make iOS apps, XCode is free. A developer license with Apple is $100/year (or free now?). It's not a whole lot compared to the money you can make back from it if you get people to use your app and pay for it.

Bootstrapping has become a very viable option for most software-based startup ideas.

No office

I obviously had to put this in here as I'm a big supporter of remote work. Not having to spend money on office rent is now an advantage. If you (and the people you work with) can work from anywhere, it also means you now have access to a worldwide pool of talent. Starting fully remote is much easier than switching to remote after you already have an entire set of office buildings and workers.

No coding skills

Not being able to code means you can use off-the-shelf tools to quickly prototype stuff without losing yourself in giant codebases. As you'll see later in this chapter, you can build an entire landing page, get data from users, process that data, charge money without writing code. This means that you can spin up lots of different MVPs and see which one sticks, without much effort. Although you're more limited in what you can make, you'll be shipping faster than people coding stuff for months.

Once one takes off, you can always learn to code on-the-fly, or get someone to help you build stuff out.

No connections

You're not a famous startup person with lots of connections in "the scene". Well, guess what. Those connections are mostly bullshit any way. And if you're "outside" the scene and not famous, it means you can act like an underdog. You'll be more indie than most and, guess what, people LOVE to support independent underdogs. You're fighting against big companies and people want to see you win, that is, until you become a big company yourself (the cycle of life). The "connections" people have after they get successful also put them in a monoculture bubble, which you're not in (yet). You think more freely and that's better for creativity.

Building a startup without coding

What if you really don't want to learn to code? That's what this part is about. You can still do it. I'll show how you can build a basic prototype with off-the-shelf tools. You'll be able to make a landing page, let users enter data, manipulate and process it, charge them money, message them and add a task for your contractor (or you) to execute, and without writing a single line of code.

I'll discuss tools to use for each section and give some examples. These tools are obviously subject to change and might be out-of-date. If they are, the general concept remains. I'll give you some guidance. It's up to you to connect everything and execute. Be creative!

Building a landing page

To get your users in you need a landing page. Luckily these days they're easy to build with existing website builders that give you templates to customize.

One of the most famous is Squarespace. A more recent indie website maker is Carrd. Others are Tilda and Wix. If you need a bit more freedom and the ability to add custom code later, try WordPress, it allows you to write PHP or JS to customize your website and add features later on easily.

You'll want to use your landing page to explain your product or service. And from there lead them towards a so-called call to action (or CTA). What do you want from your users? Do you want to save their name and email? Do you want them to pay you money? Adding a big colored button in the center top of the page as a call-to-action will lead them click there. When they click, link them to the next part (which in most cases means, collecting data from your user).

Accepting user data entry

To get people to enter data, and then save it, you can use Typeform or Google Forms. Typeform has better forms, but Google Forms lets you directly put the data in a Google spreadsheet, which is great.

Google Forms is a bit less intuitive and more formal:

Processing & manipulating user data

After you have the user's data, you probably want to do something with it. Like: save it, or process it and then save it, or process it and do something else with it as a next step. Here's where Zapier comes in. It's magic.

Zapier is a web app that lets you connect most web apps you know with others. It's like the glue in between. It can simply transfer data (or parts of data) it gets, like from a Google Sheet, a received email or a Stripe transaction, and send it to another service. Or it can process and change the data in between, it even support basic JavaScript code:

You can make your own flows to do whatever you want them to do. And they'll keep running perpetually. This is a lot like scheduled cron jobs you have on the server, but again, without coding yourself.

There's lots of pre-made flows (so-called "zaps"). Like taking data from or sending it to a Google Form: 

 

 https://pdfcoffee.com/qdownload/make-book-for-ipad-pdf-free.html