Building
How to build a startup
I’ve shipped three apps around a full-time job. None of them made me rich. All of them taught me the same ten things.
-
Solve a problem you have.
You are the only user you can interview at midnight for free. Building for a hypothetical person is how six months disappear into a product nobody asked for.
-
Talk to ten people before you write code.
Not to validate -- to find out what you’re wrong about. If ten conversations don’t change the idea at all, you asked leading questions.
-
Ship the embarrassing version.
The version you’re slightly ashamed of, shipped in three weeks, teaches you more than the polished one shipped in nine months. Reid Hoffman was right and it still feels bad every time.
-
Charge early.
The gap between “I’d use that” and “here is my card” is the entire business. Free users are a focus group. Paying users are a verdict.
-
Do things that don’t scale.
Onboard the first hundred by hand. Answer every email yourself. Paul Graham’s point holds: the unscalable phase is where you learn what to build, not a stage to skip past.
-
Pick one number.
One metric that means the thing is working, and it is almost never downloads. Every other dashboard is decoration until that number moves.
-
Cut like Jobs in 1997.
He came back to 350 products, drew a two-by-two grid, and shipped four computers. Apple was profitable within a year. Your version of that grid is smaller and just as necessary.
-
Ship weekly.
A slow cadence hides a dead product from you for months. Weekly is fast enough that you cannot lie to yourself about progress.
-
Distribution is half the product.
A good thing nobody can find loses to a mediocre thing with a channel, every single time. Decide how people will hear about it before you build it, not after.
-
Survive.
Most failed startups didn’t get out-competed, they ran out of money, time, or will. Low burn and a life you can sustain buy you the only thing that reliably works, which is more attempts.