Rules for Bootstrapped Web App Startups
Published in 2009, this chronicle by @lessallan details the mechanics of building a profitable, self-funded business without venture backing.
Core Principles for Independent Builders:
Charging customers from day one acts as the ultimate filter for building software that solves genuine, high-urgency problems.
Keeping fixed overhead low and leveraging lean infrastructure allows founders to stay alive until market tailwinds kick in.
Small, repetitive improvements in customer retention and conversion rates yield massive returns over multi-year horizons.
Community Debate Themes:
The community focused on B2B customer acquisition channels, cold email vs SEO distribution, and balancing full-time employment with side-project development.
CATEGORY Bootstrapping & MRR →
HISTORICAL ERA Web 2.0 Genesis (2007–2013)
COMMUNITY SCORE 82 points
TOTAL DISCUSSIONS 20 comments
These "rules" are a little too shallow to be very useful.
"Build something people need and love. People will talk about it."
People can only talk about it if they know about it. How will they know?
"Release, release and release. Release it before you think it's ready, you're wrong, you don't need that feature."
This would be better said as, "If you're not quite sure, don't be afraid to release. Blindly releasing for the sake of releasing is risky and stupid."
"Your app will probably fail, most of them do."
What is this doing on this list? Worst advice ever. Better would be, "Your app can succeed."
"Build something you want to use. Continue to use it, feel the user's pain."
This can easily be the opposite of #1, "Build something people need and love." You're unnecessarily restricting yourself to the relatively tiny population of things that interest you.
"Be Ballsy, don't follow the herd, make a courageous moves."
Such as...
"Build something you want to use. Continue to use it, feel the user's pain."
Bad advice. Better to ask the user about their own pain. Developers are notorious for having blind spots about their own apps.
"Google Adwords isn't a revenue model."
Not according to Markus Frind, founder of plentyoffish.com.
"Find the cheapest, fastest way to 500 paid users. People will pay for your app, if it's good."
Such as...
"Design is an iterative process, not just development. And you won't get it right the first time, so don't sweat so much."
Sweat a little. Release shit too soon and shoot yourself in the foot. Development must be done with design in mind.
"Don't scale until you actually need to. (The front page of Digg does not count as need.)"
But develop with scaling in mind. (Will you really have enough time to completely redesign your data base schema after 1000 users?)
"Don't spend any money."
What if spending money is more time/cost effective? (Paying someone to do something that would have taken me 5 days to do.)
1st rule: create a software app of high enough quality, that CS college grads from good departments will not vomit, when they see your source code
2nd rule: don't run out of money; get a part-time job; mow your neighbors lawns etc.
3rd rule: build something that companies, or any mid-sized and funded organization will actually use; you're insane to think you will actually succeed in the consumer market
my two cents. good luck.
1st rule: You do not talk about bootstrapping.
2nd rule: You DO NOT talk about bootstrapping.
3rd rule: If someone mentions real-time or social networking, it's over.
4th rule: Only two founders to a startup
5th rule: One startup at a time
6th rule: No suits, no MBAs
7th rule: Startups will go on as long as they have to
8th rule: If this is your first time at a startup, you HAVE to bootstrap.
11: If you want to be taken seriously, don't make obvious spelling errors.
This is great advice that can be applied to more than web apps too!