📄 Article
✓ Link checked
Free
Beginner
Why we picked it
The most-quoted primary source on why founders should launch fast and iterate, short, canonical, and from the co-founder of YC. Read it when you're tempted to keep polishing before launch.
From
paulgraham.com
by Paul Graham
~8 min read
- Launch fast, you haven't really started until you launch.
- Most ideas appear in the implementing, so ship to learn.
- Make a few users love you rather than many ambivalent.
Open
paulgraham.com →
✍️ Essay
✓ Link checked
Free
Beginner
Why we picked it
Graham wrote this after watching hundreds of early companies fail, so the failure patterns are observed, not theorized. Two of his mistakes go straight at trend-chasing: the derivative idea (building an imitation of whatever is hot) and the marginal niche (picking a weak market to dodge competition), both of which trace back to his root failure, not making something users actually want. It is a good starting point for pressure-testing whether you are building on a trend or just following one.
From
YC Startup Library
by Paul Graham
~20 min read
- Copying a hot company (a derivative idea) is a top killer: real startups usually start from a problem the founder personally felt, not from a trend to ride.
- Chasing an obscure corner to avoid competition is its own trap, you can only dodge competitors by dodging good ideas.
- Every mistake funnels back to one test: are real users demonstrably choosing what you built?
Open
ycombinator.com →
🧵 Thread
✓ Link checked
Free
Beginner
Why we picked it
This one line from LinkedIn's co founder is the mindset that makes buying infrastructure feel safe: the first version is meant to be rough and early, so polishing plumbing before launch is exactly the wrong instinct. It is a quick gut check when you catch yourself gold plating parts no customer will notice. Keep it handy for the moment you are tempted to perfect the wrong thing.
From
Reid Hoffman (X)
by Reid Hoffman
1 min
- An early version is supposed to feel embarrassing, that is the point
- Time spent perfecting commodity infrastructure delays the learning you need
- Ship, then improve based on real users rather than guesses
Open
x.com →
📄 Article
✓ Link checked
Free
Beginner
Why we picked it
Altman's condensed operating manual for founders, including sharp guidance on focus, spending your time on what only you can do, and prioritization. Primary source, endlessly re-read.
From
playbook.samaltman.com
by Sam Altman
long
- A founder's job narrows to a few things: set the vision, hire well, and don't run out of money
- Focus and intensity beat breadth, do a few things extremely well
- Momentum and growth are the founder's core responsibilities
- Protect your time for the highest-leverage work only you can do
Open
playbook.samaltman.com →
📖 Book
✓ Link checked
Paid
Beginner
Why we picked it
The origin text for the modern MVP and validated-learning vocabulary every founder now uses. Read it for the mental model that a startup is a series of experiments, not a single bet.
From
theleanstartup.com
by Eric Ries
~330 pages
- Progress = validated learning, not features shipped.
- Run the Build-Measure-Learn loop as fast as you can.
- An MVP is a learning tool, not a cheap product.
Open
theleanstartup.com →
📖 Book
✓ Link checked
Paid
Beginner
Why we picked it
The single best thing ever written on customer conversations. It teaches you to ask about the customer's life and past behaviour, not your idea, so you can't be lied to. If a founder reads one thing before talking to a single customer, it's this.
From
momtestbook.com
by Rob Fitzpatrick
~130 pages
- Talk about their life, not your idea.
- Ask about specifics in the past, not opinions about the future.
- 'That's so cool, I'd totally buy it' is a compliment, not data, dig for commitment and evidence.
Open
momtestbook.com →
📖 Book
✓ Link checked
Free
Beginner
Why we picked it
37signals built five products and Rails with seven people by relentlessly shipping less, sooner, and this free online book is their playbook for it. The ship-it ethos here is opinionated: launch, then fix in public rather than perfecting behind closed doors. Read the launch chapters for a concrete counterweight to feature creep.
From
37signals (Jason Fried, DHH)
by Jason Fried, David Heinemeier Hansson, Matt Linderman
Free online book
- Underdo the competition and ship the essential half first
- Launch and then keep improving in the open
- Momentum comes from shipping, not from planning
Open
basecamp.com →
📄 Article
✓ Link checked
Freemium
Intermediate
Why we picked it
Kapoor, a builder at Figma, breaks down the habits that let small teams keep a fast shipping rhythm without collapsing into chaos. It is concrete about how you organize work so shipping weekly is the default rather than a heroic push. Read it when your cadence is slipping and you want practical fixes, not motivation.
From
Lenny's Newsletter (Mihika Kapoor)
by Mihika Kapoor
20 min read
- Fast shipping is a set of habits, not a burst of effort
- Small autonomous scope keeps the release rhythm going
- Bias toward shipping and iterating over polishing in private
Open
lennysnewsletter.com →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
Charles, VP of Product at Ramp (a company known for shipping fast), lays out the operating practices that keep small teams moving quickly. It is tactical: how to scope, how to reduce dependencies, how to keep decisions from stalling. Useful once you have a team and want the concrete mechanics behind a fast cadence.
From
Geoff Charles (Medium)
by Geoff Charles
15 min read
- Keep teams small so they can move without coordination overhead
- Reduce dependencies and unclear ownership to protect speed
- Scope work tightly so something ships every cycle
Open
geoffcharles.medium.com →
📄 Article
✓ Link checked
Free
Beginner
Why we picked it
A tight distillation of what YC drills into every batch, with launch quickly and iterate as a core plank. It is the checklist version of everything above, useful for a fast gut-check on whether you are building the right habits. Read it early and return to it whenever you feel yourself drifting into perfectionism.
From
Michael Seibel (michaelseibel.com)
by Geoff Ralston, Michael Seibel
10 min read
- Launch quickly, then improve based on real usage
- Build something a small number of users love before scaling
- Talk to users continuously, not just at launch
Open
michaelseibel.com →
📖 Book
✓ Link checked
Free
Intermediate
Why we picked it
Basecamp's battle-tested, opinionated system for shipping meaningful work in fixed cycles without endless backlogs, a primary source, free in full. The antidote to over-planning your roadmap.
From
Basecamp / 37signals
by Ryan Singer
free online book
- Work in short cycles with a cool-down between them.
- Fix time, vary scope, use 'appetites,' not estimates.
- Make bets, not plans; no runaway backlog.
Open
basecamp.com →
Why we picked it
The permission slip to recruit users by hand, do things manually, and deliver 'insanely great' experiences to your first few customers. The cheapest, most honest way to validate demand is to go get it one person at a time.
From
paulgraham.com
by Paul Graham
~15 min read
- Recruit your first users manually, don't wait for them to come.
- A tiny group of users who love you beats a big group who like you.
- Manual, unscalable effort early is a feature, not a failure.
Open
paulgraham.com →
📄 Article
Free
Intermediate
Why we picked it
This tackles the exact tension a founder feels every week: ship faster or polish more. The Levels team argues that for an early-stage company velocity wins, because the most valuable thing you can do is learn by shipping experiments quickly. Read it when quality worries are slowing your cadence and you need a clear framework for the trade-off.
From
Levels (Medium)
by David Flinner
12 min read
- For early-stage companies, shipping velocity beats product polish
- Early releases are experiments whose value is the learning
- Quality bars rise later, once you know what is worth building well
Open
medium.com →
