📖 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 →
📄 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 →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
For the refactoring half of your question, Fowler explains why building for imagined future needs usually costs more than it saves. He carefully separates real over-engineering from healthy refactoring, so you can tell craft from gold-plating in your own codebase. A precise, engineer-to-engineer read.
From
martinfowler.com
by Martin Fowler
10 min read
- Do not build capability for a future you have not validated.
- Presumptive features carry build, carry, and repair costs.
- Refactoring for changeability is fine, speculative features are not.
Open
martinfowler.com →
✍️ Essay
✓ Link checked
Free
Intermediate
Why we picked it
Often the urge to rebuild comes from one abstraction that no longer fits, not from the whole codebase. Metz explains why a wrong abstraction is worse than duplicated code, and how the fix is usually to inline it back and re-split, not to burn everything down. It teaches you to make a surgical cut instead of a total rewrite.
From
sandimetz.com
by Sandi Metz
8 min read
- Duplication is often cheaper than the wrong abstraction
- Sunk-cost feelings make a bad abstraction hard to abandon
- The fix can be local surgery, not a full rebuild
Open
sandimetz.com →
✍️ Essay
✓ Link checked
Free
Beginner
Why we picked it
This is the canonical source of the ship-ugly-first idea, the LinkedIn co-founder's own essay behind the line about being embarrassed by your first version. For a solo dev deciding how much to build into a referral program before shipping, this is the judgment call at the heart of the question, launch the rough version and let real usage tell you what to add. Hoffman also draws the line on where ship-fast should not apply, which keeps it honest rather than a slogan.
From
LinkedIn
by Reid Hoffman
About a 6 minute read
- Ship the version you are slightly embarrassed by, because real user behavior teaches you what to build far faster than internal guessing
- Embarrassing is not the same as harmful: launching fast does not excuse things that alienate users or create real risk
- Speed compounds: earlier feedback means earlier iteration, which matters more than polishing features nobody has asked for yet
Open
linkedin.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 →
📖 Book
✓ Link checked
Free
Beginner
Why we picked it
This is the canonical case for building less, and its chapters Build Less and Underdo Your Competition speak straight to your question. The 37signals argument is that doing fewer things well, and skipping what you can avoid, is how a small team ships something real. Read it to give yourself permission to cut scope and lean on tools for everything that is not the point.
From
37signals
by Jason Fried and David Heinemeier Hansson
Short book, readable online
- Doing less on purpose is a feature, not a compromise, for a small team
- Every part you build is a part you must maintain forever
- Ship the smallest thing that delivers the core value, then learn
Open
37signals.com →
📖 Book
✓ Link checked
Paid
Beginner
Why we picked it
Ries gives you a working method for reading weak signals instead of guessing: build a small test, measure how real people respond, and learn fast enough to change course before a year is gone. Its most useful idea for this question is validated learning and the pivot-or-persevere call, a concrete way to decide whether an idea is worth continuing. Read it as a discipline for catching a dead-end early, not as a growth-hacking manual.
From
theleanstartup.com
by Eric Ries
~330 pages
- Validated learning means progress is measured by what you have actually confirmed with customers, not by how much you have built.
- The build-measure-learn loop is meant to shorten the time between an assumption and honest feedback on it.
- Pivot or persevere is a scheduled, evidence-based decision, so you are not drifting on an idea by default.
Open
theleanstartup.com →
📄 Article
✓ Link checked
Free
Beginner
Why we picked it
The idea that started the lean movement, from the person who coined it. No business plan survives first contact with customers, so stop defending assumptions at your desk and go test them on real people. Short, blunt, and foundational.
From
steveblank.com
by Steve Blank
~8 min read
- Your idea is a set of guesses until customers test it.
- Facts live outside the building, not in your plan.
- Expect to be wrong, and plan to learn from it.
Open
steveblank.com →
✍️ Essay
✓ Link checked
Free
Intermediate
Why we picked it
Cohen bootstrapped two companies past a hundred million in revenue, and he is blunt that a typical launch converts around one percent of traffic, so a burst of attention rarely becomes real customers. He shows why founders hide in features and launches because sales feels hard and out of their control. A sobering counterweight if a launch feels like the easy answer.
From
A Smart Bear (Jason Cohen)
by Jason Cohen
15 min read
- A typical launch converts roughly one percent of traffic to buyers
- Founders retreat to features because sales feels hard and uncontrollable
- Validate a real problem with real people before betting on reach
Open
longform.asmartbear.com →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
Turns the vague feeling of product-market fit into a number you can move. Ask users how they would feel if they could no longer use the product, then track the share who say 'very disappointed'. Under 40 percent means keep working. A test you can run on an idea long before you scale it.
From
First Round Review
by Rahul Vohra
~20 min read
- The 40 percent 'very disappointed' benchmark for product-market fit.
- Segment to your high-expectation customers and build for them.
- Make the fit score a metric you improve quarter by quarter.
Open
review.firstround.com →
📄 Article
✓ Link checked
Freemium
Intermediate
Why we picked it
Once you are testing an idea, this piece gives you concrete signals that tell you whether it is actually working, from retention curves to organic word of mouth. It collects how experienced founders and investors describe the moment an idea starts to land. Read it so you know what evidence to look for instead of guessing whether the idea is good.
From
Lenny's Newsletter
by Lenny Rachitsky
about 15 min read
- Retention that flattens rather than falling to zero is the clearest signal
- Organic growth and referrals show the problem was real
- If people would be very disappointed to lose it, you are onto something
Open
lennysnewsletter.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 →
