Day 52

We're building a startup in 80 days in public. Day 52 was on Mar 23 '22. You can find today's entry at Day 67.

Today's posts:

Magical thinking

Most startups fail. Some startups don’t launch at all. Maybe the founders get into a big fight, or they lose interest, or the product is too hard to build, or something else throws a spanner in the works. Other startups launch but don’t get any traction. Either they get no signups or the users don’t like the product. The founders then get discouraged and quit. Then there are startups that pass the first two hurdles but stumble at the third hurdle: they launch and get a bunch of happy users but they fail to monetize. Failure at different stages but failure all the same.

With our app we really want to pass all three hurdles: launching, marketing, and sales. There is some luck involved and we can’t discount the possibility we’ll fail as well. Things beyond our control can take us out. That’s part of the game and we accept that. What we don’t want is to fail because of unforced errors. We don’t want to do dumb stuff that predictably results in failure. We want to learn from other startups what works and what doesn’t.

I’m going to describe three different startup failure scenarios that I see time and time again. I’ve anonymized the stories because my goal here isn’t to make fun of people who failed but to analyze what happened so we can learn from it.

Our fictionalized founder makes three apps over the years:

  1. a desktop app that helps you organize your music collection on Linux
  2. an iPhone app that tracks and charts your grocery expenses
  3. a job listing webapp

The projects fail for different reasons but with a shared root cause. I’ll get to that later. First let’s go over these startup attempts.

Attempt 1: Linux music library app

Two common pieces of startup advice are to (1) build with the skills you have and (2) solve a problem you understand well. Our protagonist takes this advice very literally and decides to make a desktop Linux app. He has written software for Linux before and he knows he can make a better app for organizing your music.

Our heroic founder spends nights and weekends to get his music library app done. He starts coding in c++ for performance reasons, but eight months in he decides that programming that way just takes too long. The product architecture got a bit messy, so he decides it’s time for a rewrite in Rust. He doesn’t know Rust, but it’s a cool new language with smart memory management that he wanted to learn anyway. Fast forward a year later and the app kind of works. At this point the founder no longer has much passion for the idea. He’s not convinced people will buy his app. Working for two years straight in isolation is a long time and he decides he it’s time to launch. He spends two days on a website, but our protagonist has no web design skills and it looks pretty bland. He submits his site to Hacker News, reddit, and sends the link to some friends.

Crickets. His website gets a few dozen visitors. A download or two. Traffic drops to zero after a few days. Frustrated, the programmer abandons his project. He tells himself that failure is inevitable on the road to success. That failure isn’t real failure if you learn from it. He reflects on why his startup didn’t take off and concludes that the fundamental problem is that his app didn’t have a big enough audience because Linux is too niche. He figures he should have made something for “regular people”, instead. He also decides he should make something simpler.

With full determination he decides to try again.

Attempt 2: iPhone app for grocery expenses

Our founder has no particular passion for grocery phone apps but he figures that everybody shops for groceries so it should be a good and large market. If he charges $10 then for every 0.01% out of a billion iPhone users that buy his app he’ll make a million dollars (less 30% Apple fees and taxes). Previously the founder struggled with distribution and now he has Apple to take care of this for him. He also doesn’t need to worry about invoicing, credit card payments, or any of the other annoying business-y stuff anymore.

Our protagonist starts building. A year and two rewrites later he’s happy with the product and submits his app for review. His app is approved and soon after he gets the first sale! Making your first dollar of internet money very exciting. Then again, a trickle of downloads and one $10 sale per week won’t cut it if you need to make a living. But what to do? Lower the price? Ads? Rename the app? Change the logo? Translate the app to multiple languages?

Six months and many experiments later our protagonist is ready to give up. He can get more downloads if he charges 99¢ but he’s still only making beer money. Switching to in-app purchases results in more downloads, but getting people to upgrade is no mean feat. A few mean app store reviews later he’s completely done.

Okay, lesson learned, he thinks to himself. Next time, he’s going to make something SIMPLE with BUSINESSES as customers.

Attempt 3: job board

With renewed spirit our founder gets to work. Where previously he spent the better part of a year to get a prototype going now it’s just a matter of weeks. Job boards are pretty easy. What do you need? A place for people to look for jobs in their region. Search and filter by keywords and requirements. Done. What else? A backend for employers to submit new job openings. He decides a job listing costs $100 for 30 days. Slap a credit card form on the page and done.

This time our founder has a plan to get users. He’s going to contact hundreds of companies and recruitment agencies over email and LinkedIn with his pitch. He figures that by charging less than the established players he can win their business.

No dice. Companies just don’t want to advertise on an empty website. And job-seekers have no reason to visit an empty job board either. Catch-22. Our protagonist decides to reach out to a more experienced founder and asks for advice. The secret, he’s told, is to cheat. Create fake listings, fake users. Fake it all. Once you’ve got real companies and real job-seekers you can phase out the fake traffic.

The founder can’t believe what he just heard. That’s an ethical line he doesn’t want to cross. Disgusted, he concludes that startup life just isn’t for him.


Three attempts over many years amounted to nothing. Every time the founder believed he learned from his mistakes and would surely succeed next time, but he was wrong. The founder didn’t get anywhere because he learned only specific lessons: don’t make a Linux app; reaching the top of the App Store charts is hard; you can’t bootstrap a marketplace from nothing without cheating. The founder didn’t discover the root cause of his startup troubles and consequently didn’t learn anything of value. He could try five more times and he would continue to fail if he did.

The fundamental mistake this founder made is that he tried to arrive a good startup concept by reason. You can come up with reasonable sounding arguments in support for the most hopeless ideas. “Good arguments” therefore carry no weight at all.

Instead, the founder should have looked for evidence. Have other people found success with commercial desktop Linux apps for consumers? If yes, how did they succeed? Did they bootstrap, self-fund, or take VC funding? How did they find an audience? Can you find the wreckage of other people who tried what you’re about to do but failed? Why did they fail? If you can’t find success stories that’s big red flag.

It’s easy to explain failure with hindsight. There is no commercial competition for Linux desktop apps because Linux users don’t pay for software. The Apple App Store by contrast is highly competitive. You have to figure out why apps succeed and fail in app stores before you spend a year on an app of your own. You need a captive audience of businesses and professionals in search of jobs before you start on your job board or you’ll fail. But these specific explanations are not important. What matters is the process of looking for evidence that supports or invalidates your startup idea before you commit. The alternative is magical thinking and it looks like this:

The diagram doesn’t look like this in the founder’s head. The founder has all sorts of strategies and plans that sound great, but plans that aren’t backed up by evidence are just wishful thinking. If you remove everything based on wishful thinking what you’re left with looks like the flow chart above. Build. Launch. Pray. Give up. (Repeat.)

The founder also made many other mistakes. But so what? Everybody makes mistakes. Mistakes can be fixed if your startup gets the important things right. Your best best is making an original product for an established market and by applying sales/marketing strategies that are known to work.

Written like this it seems trivial. But it’s not. I see an endless amount of magical thinking by founders who earnestly believe that just making something and hoping for the best will work out for them. I’m not judging, though! We’ve also spent years on hopelessly flawed products. When we failed we totally deserved it.

I mentioned in the introduction that we intend to pass the three startup hurdles of launching, marketing, and sales. For each of these hurdles we’ve collected clear indicators that our general approach should work. We’re intentionally a “single miracle startup“. We’re taking an educated gamble with our product, but our marketing and sales will be conventional and straightforward. Our plan may fail, but we have a real plan.

← Previous day (day 51)Next day (day 53) →

You can follow us on Twitter @jdvhouten and @wcools and look for #80daystartup

Read more

Work/new-life balance
Durable tech
Early user feedback
Spending time to save time
Products want to be platforms
Always be launching
Enjoying the journey
Work-life balance
Recap @ Day 59
Perils of caching
Making sense of contradictions
Trust signals
DIY javascript error logging
Taxes: an automation story
Magical thinking
Start small
High conviction, low conviction
Most deals fail

Post archive