Bootstrapper's Handbook: Building Startups the Indie Way PDF

make BOOTSTRAPPER'S HANDBOOK building startups the indie way by Product Hunt's 2x Maker of the Year + founder of Nomad List + Remote OK + Hoodmaps Pieter Levels Contents Foreword 0.1. Thank you 0.2. Why did I write a book? 0.3. But I do want to write a book 0.4. The indie way of building a startup 0.5. I want to make bootstrapping great (again) #MBGA 0.6. Why should you listen to me? 0.7. This book is my entire brain dump 0.8. This book is continuously updated 0.9. App, site, product, startup, business 0.10. You'll need persistence, and luck 0.11. Practice This book Idea 2.1. Introduction 2.2. Solve your own problems 2.3. Your problem might just be everyone else's 2.4. You are the greatest expert at your own problems 2.5. How well do you need to know a problem to solve it? 2.6. Be more original, and your ideas will be original 2.7. The downside of solving only your own problems 2.8. Always start from the problem, not the solution 2.9. To get big, you have to start small 2.10. Start with a micro niche 2.11. From micro niche to multi-niche 2.12. From multi-niche to vertical integration 2.13. From vertical integration to becoming a platform 2.14. You just became big by starting small! 2.15. Your idea does not have to be earth-shattering 2.16. Create a list of ideas and keep track of them 2.17. Should you make ideas alone or in a group? 2.18. Don't be afraid to share your ideas 2.19. Conclusion 2.19.1. Resources mentioned 2.19.2. Your homework Build 3.1. Introduction 3.2. Build fast and minimal 3.2.1. Downsides of fast development 3.2.2. Your enemy is perfection 3.2.3. How viable should a minimum viable product (MVP) be? 3.3. Build yourself or outsource 3.3.1. DIY vs. people who hire others to do it for them 3.3.2. DIY vs. big teams with VC money 3.3.3. My gripe with venture capital in terms of building products 3.3.4. Bootstrapping vs. venture capital 3.3.4.a. The importance of keeping costs down 3.4. To build, should you learn to code? 3.5. Tools 3.5.1. Which tools should you use to build? 3.5.2. My "light" stack 3.5.3. Why are people so obsessed with tools? 3.5.4. How do you evaluate if a new tool is useful for you? 3.6. Native vs. web 3.6.1. Web 3.6.2. Native 3.6.3. User experience and development 3.6.4. Updating native apps vs. web apps 3.6.5. Hybrid web + native apps 3.6.6. What are people using most? 3.6.7. A future where your web app lives inside other native apps 3.6.8. The web and native will merge in the future 3.6.9. Learn both 3.6.10. What are you able to build now? 3.7. Building with constraints 3.7.1. No money/investment 3.7.2. No office 3.7.3. No coding skills 3.7.4. No connections 3.8. Building a startup without coding 3.8.1. Building a landing page 3.8.2. Accepting user data entry 3.8.3. Processing & manipulating user data 3.8.4. Contacting users 3.8.5. Making tasks for contractors 3.8.6. Charging users payments 3.8.7. Okay, let's try build something 3.9. Let's talk APIs 3.9.1. Why are they useful? 3.9.2. You can build a business on other people's API's 3.10. Conclusion 3.10.1. Resources mentioned 3.10.2. Your homework Launch 4.1. Introduction 4.2. What is a launch? 4.3. Why even launch? 4.4. How fast should you launch? 4.5. Preparing your app for a launch 4.5.1. Fix most bugs 4.5.2. Add an email box 4.5.3. Add push notifications 4.5.4. Set up analytics 4.5.5. Feedback box 4.6. Where to launch? 4.6.1. Typical places to launch a startup 4.6.1.a. Launching on Product Hunt 4.6.1.b. Launching on Hacker News 4.6.1.c. Launching on Reddit 4.6.1.d. Launching on Beta List 4.6.1.e. There will be hate 4.6.2. Things not to do 4.6.2.a. Asking people to share/like/post your product 4.6.2.b. Buying fake upvotes, likes, followers 4.6.2.c. So why doesn't this work 4.6.2.d. Be organic 4.6.3. Telling your story 4.6.3.a. Blog 4.6.4. Press 4.6.4.a. Why press matters 4.6.4.b. Why press increasingly matters less 4.6.4.c. How to get press 4.6.4.d. Which press outlets 4.6.5. Don't stick to one launch, keep launching 4.6.5.a. Make every feature a launch opportunity 4.6.5.b. Side project marketing 4.7. How to stay motivated working on one product 4.7.1. If it doesn't motivate you, sell it or kill it 4.7.2. How many ideas should I work on at a time? 4.8. Conclusion 4.8.1. Resources mentioned 4.8.2. Your homework Grow 5.1. Introduction 5.2. Why is organic growth better? 5.2.1. Especially...fake users 5.3. How to get organic growth 5.3.1. Get new users 5.3.1.a. Keep launching 5.3.1.b. Spinning off 5.3.1.c. Tell stories to people & press 5.3.1.d. Build in public 5.3.1.e. Make people share easily 5.3.1.f. Human-readable URLs and slugs 5.4. Launch an API 5.5. Build with your users 5.6. Measure how you stand up against your competitors 5.7. Conclusion 5.7.1. Resources mentioned 5.7.2. Your homework Monetize 6.1. Introduction 6.2. Why is monetization so important? 6.3. Don't be afraid to charge money 6.4. Charge money, get hate 6.5. Build with monetization in mind 6.6. Monetization is validation 6.7. Business models 6.7.1. Limit features to paid users 6.7.2. Pay-per-feature 6.7.3. Ads 6.7.4. Sponsorships 6.7.5. Patronage 6.7.6. Subscription-based memberships 6.7.7. Community model 6.7.7.a. The story of Nomad List's paid membership community 6.7.8. Job boards 6.7.9. Conditional payments 6.7.10. Productizing an agency into a SaaS 6.7.11. Learn from your competitors' business models 6.7.12. Keep experimenting with business models 6.7.13. When are you done monetizing? 6.7.13.a. It depends on your objectives 6.7.13.b. How big do you want to be? 6.7.13.c. Widen your market 6.7.13.d. Grow the pie 6.8. Payment platforms 6.8.1. Stripe 6.8.2. Braintree 6.8.3. PayPal 6.8.4. Local alternatives 6.8.5. Stripe Atlas 6.8.6. Use a combination of platforms 6.9. Use a Typeform to charge fast 6.10. How to deal with refunds? 6.11. How to deal with bookkeeping and tax? 6.12. Conclusion 6.12.1. Resources mentioned 6.12.2. Your homework Automate 7.1. Introduction 7.2. How is automation relevant? 7.3. What's a robot really? 7.4. Don't automate if it's not worth to automate it 7.5. Where do humans fit in here? 7.5.1. What if the robots can't fix things themselves. How do the robots ask the humans for help? 7.6. So this is like passive income, right? No! 7.7. The "bus test" 7.8. Conclusion 7.8.1. Resources mentioned 7.8.2. Your homework TL;DR Introduction Because you have little time, here's the mega short TL;DR (too long; didn't read) summary of this book. Idea Get an idea from problems in your own life. If you don't have problems that are original enough, become a more original person. Don't build products that are solutions in search of a problem. Build Build your idea with the tools you already know. Don't spend a year learning some language you'll never use. Don't outsource building to other people, that's a competitive disadvantage. Build only the core functionality. The rest comes later. Launch Launch early and multiple times. Launch to famous startups websites (like Product Hunt, Hacker News, The Next Web), mainstream websites (like Reddit) and mainstream press (like Forbes). But also remember to find where your specific audience hangs out on the internet and launch there. Launch in a friendly way, that means "here's something I made that might be useful for you", instead of acting like you're some big giant new startup coming to change the world. Grow Grow organically. A great product that people really need which is better than the rest will pull people in. You don't need ads for that. Don't hire people if there's no revenue yet. Don't hire many people if there's revenue either. Stay lean and fast. Do things yourself. Monetize Monetize by asking users for money. Don't sell their data. Don't put ads everywhere. Don't dilute your product. Be honest that you need money to build the product they love and they'll be fine paying for it. Automate Automate by writing programs that do stuff that you do repeatedly. Only automate if it's worth the time saved. For stuff that's too hard to automate or not worth it, hire contractors. Let them work as autonomously as possible. Where possible let robots manage them (for example by giving them alerts when things happen in your product). Ethics Not a chapter but important: be ethical, and don't cut corners on ethics. You'll be rewarded by not doing dodgy stuff like spamming, manipulating your users into doing stuff, growth hacking your search rankings or faking your social media, or abusing your power to compete unfairly if you're successful. If you make a good product, you don't need any of this. If you make mistakes, own up to them and say sorry. Be nice as a person and especially as a company. Karma always pays back in the end. Just being ethical and nice is a competitive advantage these days because most companies (and people) are not! Homework Homework: Each chapter ends with homework exercises that you can do. Instead of just reading, I'd like you to use this book as a handbook while actually building and shipping a product. It doesn't matter if it fails. But you need to do something instead of just read! This is not startup porn! This is startup life. Foreword Thank you The last years were a whirlwind of adventures while building all these prod- ucts and being part of the startup ecosystem. I've met hundreds, maybe thou- sands 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 (espe- cially 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 (Moeps), dad (Aap), Jeroen Pixel and Marijn for sticking with me and giving me true advice in times where it was impossible to get objective feedback anywhere else. I'd like to thank Youjin Do 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 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 UDL squad for their radical honesty, intellectual prowess and scholarly approach to reviewing my writing. And keeping me grounded as a human by being consistently unimpressed and laughing at my internet celebness. 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. It changed my life. 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 out-dated 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 build- ing 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 chang- ing 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 re- mote jobs board in the world with 1 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 90%), and highly automated. I was Product Hunt's Maker of the Year twice. I've launched my startups to Reddit's frontpage twice. I grew my projects together into $50,000 monthly revenue while blogging and tweeting about all the personal ups and (lots of) downs for the past years. 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. 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 boot- strapped 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 peo- ple'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 continous 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 ex- perience 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 de- scribed 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 $30 to support it. The only thing people received after paying $30 immediately was an empty Workflowy list where they could write what the book should be about specifi- cally. 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 rev- enue at $30 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. Every- one 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 pub- lic" 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 edi- torial 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 chal- lenges are. Then you see if you could make those challenges easier using tech- nology. 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's 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 spread- sheet. 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 doc- tors 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 some- thing 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 trav- eling 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 visit- ed 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 compa- nies 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. Every- body's doing some kind of photo sharing app. These are basic ideas that every- one 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 attrib- utes 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 off. Jump off cliffs (do it safely). Ask people you like out. Walk into random office buildings. Jump fences. Crash hotel pools. Whatever makes you different. Don't be so 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 develop- ing country and solve the problematic garbage situation there. It's the privi- lege argument. I get it. And I see the criticsm 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 prob- lem. 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 some- thing. 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 technol- ogy. 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 be- cause 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 $167/month for 1 500 people pay you 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 $9/month for 1 year you 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 migh 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 pay- ing $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 lowest resistance. Your com- pany should be doing the same thing. From multi-niche to vertical integration Now let's say you have the entire booking for hairdressers market, what about booking for nail salons? And tattoo shops? Oh 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 is on them first). This is vertical integration, you try to go into the businesses that your current customers also use. From vertical integration 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 plat- form that will change everything. But hardly anybody started with that. Face- book was a Hot Or Not app by Marc Zuckerberg. Apple was a personal comput- er 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 ex- periment 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 star- tups, 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 trans- port 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 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 em- brace 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 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 have probably 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's 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 previ- ously 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 some- body else in a team, there's a big tendency of group-think, 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 cus- tomers. 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 No = 0 = $0 idea execution Good Good = 10 = $100,000 idea execution Great Great = 20 = $1,000,0000 idea execution "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 execu- tion" (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 lov- ing 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 group-think 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 zeit- geist of our time is transient too. Evertything moves fast now, and where in the past people would use an app for days or weeks, now you literally have sec- onds 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 ac- cept 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 re- write 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 iter- ations 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 ser- vice 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 back- ground 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 devel- op it to be great later. Why not perfect it step by step? Make small improvements. There's a limit though to this though. Don't make shitty products. With mini- mum 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 MVP's 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 func- tion, 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, hav- ing 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 mes- sage 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 man- aging 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 were 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 were 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 bangs 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 better shit than other people and it gets rewarded. 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 peo- ple's) money wasted on bullshit. And there's plenty of VC money funding bull- shit. 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 thng 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 cashflow 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 owner- ship 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 your- self. A simple web server is $5/month. A code editor like Atom 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 start- up 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 de- mand 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 1000s 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, 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 rev- enue. 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 devel- oper 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 con- tinuous 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. Al- most 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, boot- camps 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: EUREUKA! 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 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 pro- gramming 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 be- came 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 mat- ter for you. What if you don't code? I'd recommend you to learn to code of course. But for you, I've written 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 Com- puter 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 (any- thing.JS etc.) or language (Ruby etc.) to program. I knew some PHP from mak- ing 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 back-end (server). This back-end can run anything. I use PHP, but nowadays you can also run Java- Script on the server (with Express or Node.JS for example). You separate the back-end (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 back-end 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 liter- ally 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 obtruse, 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 back-end) 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 built 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 re- peating. 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 devel- opment 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, be- cause 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 (especial- ly 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 build- ing 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 Java- Script": 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 lan- guage 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. Wheras with a web app, all you have to do is click on a link from another website (like Face- book, 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 recent- ly, 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 proba- bly 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 us- ing 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 lon gterm, there are a few obstacles to overcome for the two to converge. Honestly though, it's impossible to predict. Five yers ago, I would have though 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 na- tive 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 learn- ing Objective-C and Swift to get an iPhone app out, or paying a mobile devel- oper $25,000 to build it for you. Remember: you can ALWAYS go native later. If people use your site al- ready, 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 in 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 your- self. A simple web server is $5/m. A code editor like Sublime Text is $60. To make iOS apps, XCode is free. A developer license with Apple is $100/year. 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 start- up ideas. No of ce 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 proto- type stuff without losing yourself in giant codebases. As you'll see later in this chapter, you can build an entire landing page, get data form 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 peo- ple 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 inde- pendent 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, manipu- late 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 gen- eral 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 abili- ty 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 form 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 with 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: Or taking the data from Typeform and sending it to Dropbox: Contacting users After you have processed the data, you might want to contact your users. Luckily, Zapier supports MailChimp, which means you can now automatically send emails: Or you can just give a nod to MailChimp to do something. In turn, MailChimp has advanced built-in automation too: That means anything you'd want to do after a user lands on your site and en- ters data is possible. Like send them an email 14 days after with a link to an- other web app. Or send them an automated PayPal invoice within an hour of signing up. It doesn't stop with email. You can send an SMS message or robot-voice phone call to your user with the telephone API service Twilio. Then you can even save what they respond on the phone. And in turn, send that to another web app! Making tasks for contractors What if you need a human to process some data or work with a user? Send it to productivity software Trello, where you add it as a to-do list item for your con- tractor to execute: Charging users payments One of the most important parts is actually getting users to give you money. Until recently, this was reserved to people who could code payment logic to- gether. Not anymore. Website builder Carrd supports Stripe Checkout, which means you simply connect your Stripe account and you can accept payments on your landing page. Okay, let's try build something To prove to you this works, I want to build an MVP for a startup that picks up luggage anywhere in the world (where you are) and ships it to your destina- tion. This way, you don't have to go to the airport carrying all your bags around. We won't write any code. Let's start making a landing in Carrd's editor: Here's how the final version looks: Then when we make a new Typeform asking the user for their address, pick up date and we embed this Typeform into Carrd: The good thing about Typeform is it also supports Stripe. So we can also charge the user's credit card from within (!) the form: Now let's go into Zapier and make sure that after payment happens we do a few things. This Zapier zap only runs if a new paid entry hits the Typeform. We automatically send an email to the customer using Gmail with information about the pickup: We automatically add the pickup order to our Google Sheet with active pick ups: We automatically add a task into Trello for our pick up contractor to get the luggage: We also automatically SMS our contractor an alert with Twilio that there's a new pick up ready to be fulfilled, with the date and address: See how easy that was? We now have a fully functioning minimum viable product (and actually a basic startup) built. And it took about 30 minutes! You can go a lot more complicated from here. The possibilities are endless. And when you have validated your non-code MVP, you can start adding your own coded parts too to increase the complexity of your product. You can replace the "off-the-shelf" web apps with your own coded scripts. Let's talk APIs The entire previous section where we connected all these web apps without code is only possible because of the existence of so-called APIs. They're Appli- cation Program Interface. Which simply means apps that can communicate to each other in slightly human-readable data. Zapier's entire app is build around connecting different APIs together. You don't need to use Zapier to use APIs though. If you can code, you can query APIs too and save their data, and in turn send it to other APIs. One of the easiest ways to quickly build a prototype (if you can code) is to use thse third-party APIs. They can provide you with data (like cost of living or weather data), platforms to build on (like Facebook and Twitter) and services (like sending emails easily). Why are they useful? APIs are ways that computers and servers can share data in a computer read- able format. It means that when I open https://nomadlist.com/amsterdam- netherlands a computer will literally read this: Nomad List - The Best Cities to Live and Work Remotely try{Typekit.load();}catch(e){}....etcetera (it goes on for pages). This stuff is nice to look at when the comput- er visualizes it and interprets the HTML code. But it's hard for the computer to get specific data from it. Because the layout is kinda made for humans. But now, if I open the same page through an API at https://nomadlist.com/api/v2/amsterdam-netherlands (this URL will probably not work anymore when you read this book but you get the point), you and I, and even a computer, will be able to read this: { "name":"Amsterdam", "country":"The Netherlands", "cost_of_living":"$2,500/m", "safety_score":4.3891, "nomad_score":4.2183, "fun_score":3.394, "cost_score":2.238 } Now you can get the city name Amsterdam, the country The Netherlands and how fun it is there 3.394 (out of 5 stars) and display it on your own site. That's useful. But even more useful is if you combine multiple APIs together. What if I want to find the most fun places from Nomad List, and get the live weather data from somewhere else? To see where it's fun and not raining? Well, just a quick Google for "weather api" reveals there's a free weather API called OpenWeatherMap.org which can give you the current weather and forecast in a computer readable format, just like above. Let's try it: http://api.openweathermap.org/data/2.5/weather?q=Amsterdam { "name":"Amsterdam", "coord": { "lon":53, "lat":4 }, "weather": [ { "main":"sunny", "description":"clear sky and sunny" } ], "main": { "temp_celsius":25.5, "humidity":89, "pressure":1013, "temp_min":20.04, "temp_max":26.04 }, "rain": { "3h":0 }, "clouds": { "all":5 }, } Yay, it's not raining in Amsterdam! And it's actually 25 degrees celsius! That means we can go outside and have some drinks :) Now we can combine that weather API data, with the data from the Nomad List API and show it on our site. But we can go much much further. With API services like Twilio.com, we can make an entire telephone voice and SMS service by just making calls to their API. I'll spare you the technical de- tails as it's quite some work. But it's not difficult. It's simple and anyone can set it up. Now start thinking of ideas. You can have a phone number you call that'll ask you some questions over voice, and even have the person answer them (yes Twilio has Speech-To-Text and Text-To-Speech). You can call that number to ask what's the city you should go now with the best weather and most fun. The more APIs you start combining, the more fun it becomes. And because the heavy load is lifted by the APIs already, you are pretty much just connecting them together into new functionality. Which can be your product! You can build a business on other people's API's You can build entire businesses based on other company's API's. Many have done so before you. There's one big thing to remember though: if you become solely dependent on one company's API, you're in a bad place. Without even telling or asking you, they can shut down their API at any time. And that will immediately destroy your business. More commonly, companies change how their APIs function whenever they want. That means you have to constantly monitor their API and see if it func- tions correctly. Whenever they change something (even something as small as changing the key of "nomad_cost" to "nomadcost"), it will break your app and you have to change your code. Conclusion When building, try to build fast and minimal. Instead of learning new stuff, use the tools you already know to build your idea. Make sure your MVP actual- ly works and is not just a landing page that doesn't do anything. Lose your per- fectionism, it'll never be perfect any way. Don't outsource, build it yourself. If you can't code, use off-the-shelf tools and connect APIs together to build it. Appreciate your constraints and limitations, they can be a giant advantage vs. people with lots of resources. Keep your costs low while building and later on. Build for the web first, you can go native mobile later. Don't build on an MVP too long, a good rule of thumb is to spend max. one month on it and launch. Resources mentioned Linode Digital Ocean Heroku Ubuntu NGINX Olark Twilio Zapier WordPress.com Your homework Rank the list of ideas you made previously by which you think are best. Now see which of those best ideas you can execute quickest with the tools and skillset you already have right now — that means without learning anything else now. Build the first prototype of your idea, it's minimal, but that doesn't mean not functional. It should do something, either it being a Typeform connected to Zapier or a WordPress landing page or your self-programmed web app or native app. It should have the core functionality working well to be useful for users. Launch Introduction Congrats! You've built something. Now for the most important step, launching it to your future users. What is a launch? Many people have talked about it. Some have tried. Yet few have succeeded. It's the launch of your app. After getting your idea and putting all your effort into building it. This is the day. You show your product to the world in the hope of getting people to use it (and pay for it). But most people are overconfident. They think it's easy. It is relatively easy if you have a great product. But even then, a wrong launch can mean failure on day one. That's why the launch is probably one of the most important parts of doing a startup. In effect, what it means is getting your app in the hands of people so they start using it. And there are lots of ways to go about it. You can get people to know about your app through existing platforms like Product Hunt, Hacker News or Reddit. You can do outreach to press, so they'll write about it. You can try to get people with a big audience to use it. There are many ways, and we'll discuss most of them in this chapter. Why even launch? The idea of having a first launch is to make a big splash, get lots of people to use your app, learn from their usage, fixing bugs, developeing new features, and hopefully getting them engaged so they stick around. You want to bring lots of people in quickly, so that the app becomes active and so people start talking about it. It's also a great press opportunity, a launch itself means you can get press from it. Even if it just means making your app publicly accessible by deploying it. If you don't launch it, nobody is going to show up and use it. Launches can and mostly are arbitrary these days. With continuous develop- ment, you kinda launch every few hours, right? But you need to pick a certain day and time to make this into an event. Let's say you have lots of new updates and you feel like now it's almost like a new product. Then you can launch it and tell the world. How fast should you launch? In most cases, you should launch as fast as possible. Because you want to have people using it. Why? Because then you can figure out if they use it, how they're using it and if they don't, why not? You can find bugs you haven't found yourself. And you can get direct feedback from users to improve it. Preparing your app for a launch One of the most important things to do before launching is seeing if what you made is actually launch-ready. Many people have the wrong idea about the term minimum viable product (or MVP). You can't just throw something together and call it an MVP and put it up. It needs to actually work. 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. So make sure it has a function. It does something well. Fix most bugs Then make sure that most bugs are gone. Go through the flow of what a new user will go through many times. Act like different users. If you send out emails after a user signs up, see if they actually get it. Go through that flow countless times, until you're sure it actually works. If you think all bugs are gone, make sure you get a few more people to check it out. It's easy to miss things because you're so deep in your own app's development. Add an email box One of the smartest things Product Hunt did, and many copied, was to add an email sign up box at the top of their page. They've since changed it. But it was smart as it gave them the ability to re-engage users. So how should it look? Adding just "subscribe to my newsletter" sucks! It doesn't show people value. The last thing I want if I go to your site is to sub- scribe to another newsletter. Instead, give me something useful and customized: For example, if you have a jobs board and I'm browsing the PHP jobs: That's actually useful to me. Instead of thinking about how useful getting their email address is to you, think about what would be useful to a new user so that you can capture their email address. What if you have a food delivery service (now that's a startup idea nobody's done yet, /sarcasm!): You can set up a free MailChimp account and start capturing addresses with their standard form. You can also add custom fields (like their city), so that you can email them later depending on their city (that's called segmenting). Doing this is important as it gives you the ability to capture the audience that comes to your site on the day of your launch. And then get (some of) them to come back in a few weeks. This is so critical, because most sites see a giant drop of traffic after their launch ends. And that literally means, you've now got a app that nobody uses. Add push noti cations This applies just as much to a native app as a web app. With a native app you have even more options though. You have push notifications which if you don't abuse them are incredibly valuable. You can literally push yourself to a user's most intimate device (their smart phone), straight on to their home screen. Be extremely modest with push notifications though. If you overuse them, and they're not relevant, people will disable them. To use my earlier example of the PHP jobs app, if I sign up to be notified about PHP jobs then you should send me a notification if there's a particularly good PHP job available or if there are X amount of PHP jobs available that you can show me grouped together each week. That way, you give me something useful and you're not spamming me. Set up analytics Something so common, but yet so many people for

Bootstrapper's Handbook: Building Startups the Indie Way PDF

Document Details

Tags

Related

Summary

Full Transcript

Upgrade to continue