This book is freely available online.

• Build less. Underdo your competition. One-upping your competition is a dead-end mentality. It's expensive and paranoid. Lead, don't follow.
• Build software that solves problems you care about.
  • Your passion - or lack thereof - will shine through.
• Aim to fund yourself.
• Constraints force creativity. Embrace them. They drive innovation and force focus.
• Flex your scope to fix time and budget. Don't just throw more resources at the problem.
• A good heuristic for knowing what your app should be is knowing what it shouldn't be. Find an enemy so you'll know where you won't go.
  • This also gives you a clear marketing message.
  • Don't get too obsessed with competition.
  • Don't follow the leader. Again: don't just try to outdo. Do differently.
• Be agile. This requires you to have less mass. That is, you should be lean.
  • Lower your cost of change.
• You only need 3 people for version 1.0 of your product. 1 developer, 1 designer, and someone who can do both.
• Differentiate yourself from bigger companies by being personal and friendly
  • Like Paul Graham says: do things that don't scale.
• Define the one vision for your app. What's it really about? You need to know this. Think big. What is the purpose for it's existence?
  • This is your guiding light.
  • It's also why your software should be opinionated. If you accept every request, it'll be a bloated mess. Take sides.
• Ignore details early on.
  • There's a common saying in the indie hacker community "If your site has X, you launched too late." where X can be anything more than a 'buy now' button: a footer, a forgot-password feature, unit tests, and so on.
• Don’t waste time on problems you don’t have yet. Avoid premature Optimization.
  • You don't need Kubernetes, DynamoDB, etc. now. You need to find PMF.
  • Worry about scalability later.
• If you try to please everyone, you won’t please anyone.
• Build half a product, not a half-ass product. Do only what's truly essential, and do that well. You can set aside good ideas and focus on the great idea.
  • Features should work hard to be implemented. Requests should be met with "not now" immediately. Only if the requests for it keep coming do you start considering it.
  • "Innovation is not about saying yes to everything. It’s about saying NO to all but the most crucial features." - Steve Jobs, told by Derek Sivers.
• The best programmers & designers aren't the fastest typers, the ones with the best skills, or whatever. It's those that can prioritize. They can determine what matters and what doesn't.
• Build software for general concepts and encourage people to create their own solutions.
• Get something real up and running quickly. Early feedback matters.
• Work in iterations. You won't get everything right at first. But you'll get there if you keep trying & getting feedback.
• From Idea to Implementation – the process used to Get Real:
  • Brainstorm. Come up with ideas. What will the product do?
  • Paper sketches. Do quick, dirty, cheap sketches.
  • Create HTML screens of the feature/section/flow. Get it out there. Get feedback.
  • Code it.
• Avoid preferences – decide the little details so your customers don’t have to.
  • Adding more customizability options isn't always the best path. You should be using your expertise to make the path, not outsource it to your customers. Don't make them work for it.
  • If you make a bad call, people will complain, and you adjust.
  • Design good defaults.
• Test in the wild. Release beta features to people in the app — A/B testing. Don't have a beta version & release version. It should be the same thing.
• Don't have estimates that stretch into weeks or months. Those are fantasies. You don't know what's going to happen that far in advance.
  • Break your timeframes into smaller chunks. 12 week project? 12 projects. 30 hour task? Break it into 6-10 hour chunks.
• People need uninterrupted time to get things done. Make half the day alone time. That's when people get work done. This period should be contiguous to avoid productivity-killing interruptions.
  • See also Maker vs. Manager.
  • During alone time: no IM, calls, meetings, emails.
  • Get in flow.
• Avoid meetings. If you do have to have one, make it 30 min max, only invite the necessary people (as few as possible), and never do it without a clear agenda.
• Get small victories. Long, drawn out release cycles are motivation killers. If you're in such a cycle, dedicate a day a week to small victories – what can you do and release in 4 hours?
• You don't need as many people as you think. Hire less and hire later.
• Design the interface first. Program later.
• Focus on the epicenter when designing — if you're making a blog page, the post is the most important. Footer, navbar, etc. comes later.
• Design for regular, blank, and error states. Consider these for each screen:
  • Regular = everything is working fine
  • Blank = no data yet
  • Error = something has gone wrong
  • It's not enough to just design for the happy path.
  • The blank state is where your user makes their first impression.
  • You can add quick tutorials, help blurbs. Give samples of what the page looks like with content. Explain how to get started. Explain where to go from here.
• Design for when things go wrong. Because they will. Make good error screens. Don't let your users feel abandoned.
• Have less software (code). Solve as much of the problem as necessary with as little code as possible.
• Have free samples to lure in users. Give value.
• Make it as easy as possible to get in and out of your application.
  • Ideally have an option to let people try without entering credit card info.
• Avoid long term contracts, sign-up fees, etc. Monthly billing is so much simpler. Cancel anytime. Don't find tricky or clever ways to get more cash. Earn it.
• Need to give bad news (e.g. price increase)? Make it painless by giving plenty of advance notice. And consider a grandfather period where existing users are exempt for a period of time.
• How to launch
  • Tease a few months ahead of time. Drop hints. Post logos. Post to your blog. Be vague, but drop hints. Set up a site to collect emails from interested people.
  • Preview a few weeks ahead of launch. Preview features. Give behind-the-scenes. E.g. post screenshots. Give early access (to early adopters). Encourage people to leave their emails.
  • Launch. Let people sign up. Send emails to those who gave them. Launch your full marketing site. Get blogs to link to you. Post progress - how many signed up? What did up update? Show momentum and keep at it.
• Promotion could be an app overview, tour, screen captures & videos, manifesto (philosophy behind app), case studies, buzz (testimonials, reviews, press), forum, pricing & sign up, and a weblog.
• Another good way to promote is by sharing your knowledge. Posting tips & tricks, speaking at conferences, conducting workshops, giving interviews, writing articles or books.
• Figure out who's talking about you and make your presence felt. Leave comments there. Thank people for posting links. Listen to negative feedback.
• Upsell within your app. Promote upgrade opportunities. Eg. by showing you'll remove barriers if users upgrade.
• Make your app's name ease to remember. Short, catchy, and memorable.
• Your development/design team should directly interact with customers. Do not outsource your customer service to a third party. Do it yourself.
• Build a tool that doesn't require a manual. Keep things simple. Use inline help & FAQs.
• Answer support requests quickly. Ideally within 90 minutes or less.
• Be willing to say no to your customers. You don't have to implement every feature they ask for.
• If something goes wrong, tell people. Even if they never saw it in the first place. Be honest, open, and transparent. Bad news should be like tearing off a band aid – as fast as possible. But you should trickle out the good news. Keep the good vibes going as long as possible.
• Show your product is alive - keep the blog going. Update frequently. E.g. FAQs, how-tos, tips & tricks, update logs, buzz/press.
• Don't use "beta" as a scapegoat. It's a cop out. Nothing is ever perfect.
• You don't need to fix every bug. Prioritize them. Ignore some. Consider how many are affected and how bad the problem is. Can it wait?
• If you change something, there can be knee-jerk reactions. Wait 24-48 hours before changing it back - let things settle down.