✍️ 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
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 →
✍️ Essay
✓ Link checked
Free
Intermediate
Why we picked it
The free, original essay that defined the MVP before the book existed, written plainly by the person who coined the term. It clears up the most common mistake founders make, which is thinking an MVP has to be a working product when a landing page or a video often teaches you more, faster. Useful as a quick primer you can send someone in one link.
From
Startup Lessons Learned (Eric Ries)
by Eric Ries
~15 min read
- An MVP is the smallest thing that produces validated learning, not the smallest product
- A page or a video can be a legitimate MVP if it tests real demand
- Aim for maximum learning per unit of effort, not feature completeness
Open
startuplessonslearned.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
Blank, who built customer development, uses a real founder story to show how a team defaulted to 'build a smaller product' when the right move was a test that cost almost nothing. The piece pushes you to name your riskiest assumption and design the cheapest possible experiment against it. It is a direct match for the idea that your MVP might be a conversation or a fake feature, not code.
From
steveblank.com
by Steve Blank
7 min read
- Start from the assumption that could kill you, then test only that
- The cheapest experiment that answers the question beats a small polished build
- You are selling the vision but delivering the minimum feature set
Open
steveblank.com →
✍️ Essay
✓ Link checked
Free
Beginner
Why we picked it
A runaway roadmap is usually a list of every decent idea, and this piece is the antidote. Build half a product that is great rather than a full product that is mediocre, then cut the feature list in half again. For an early founder tempted to plan quarters of features, it reframes cutting as the point, not the compromise.
From
Basecamp (37signals)
by Jason Fried, David Heinemeier Hansson
~3 min read
- Ship half a product, not a half done product
- Cut your feature list, then cut it again
- Real usage, not a plan, tells you what to build next
Open
basecamp.com →
✍️ Essay
✓ Link checked
Free
Intermediate
Why we picked it
Cohen argues the MVP framing pushes founders to ship something too broken to love, and offers an alternative: make it Simple, Lovable, and Complete instead. It sharpens the cut so you remove scope without removing quality on the one thing you decide to keep. A useful corrective to "just ship anything."
From
A Smart Bear (Jason Cohen)
by Jason Cohen
~12 min read
- Cut breadth, not quality, so the one workflow you keep is genuinely good.
- Simple and complete beats broad and half-working.
- A narrow product people love earns more than a wide one people merely tolerate.
Open
longform.asmartbear.com →
📄 Article
✓ Link checked
Free
Beginner
Why we picked it
Traynor's cupcake metaphor says your first version should be small but whole and enjoyable, a real cupcake rather than a slice of unbaked cake. Every early release should deliver actual value to the user, not a broken preview of a bigger dream. It is a memorable way to decide whether your rough version is small-and-good or just unfinished.
From
Des Traynor, Intercom Blog
by Des Traynor
5 min read
- Ship a small complete thing, not a fragment of a big thing
- Each version should deliver real value on its own
- Rough is fine if it still works, a broken slice is not
Open
intercom.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 →
✍️ Essay
✓ Link checked
Free
Intermediate
Why we picked it
The essay that put 'product-market fit' into the startup vocabulary. Read it for the gut-level description of what PMF feels like when it's happening vs when it isn't, the intuition behind the metrics.
From
pmarchive.com
by Marc Andreessen
~15 min read
- Market matters most; a great market pulls product out of a startup.
- You can feel PMF, customers buy as fast as you can ship.
- Before PMF, do whatever it takes to get there; nothing else counts.
Open
pmarchive.com →
✍️ Essay
✓ Link checked
Free
Beginner
Why we picked it
This is the canonical framing for exactly your question: not all messy code is the same. Fowler splits debt on two axes, whether you took it on deliberately or by accident, and whether the call was prudent or reckless. For a two-person team shipping fast, the useful cell is deliberate and prudent: you know you cut a corner, you thought about the payoff, and you plan to come back. That is a healthy place to be, and this piece gives you the language to tell it apart from the reckless kind that actually hurts.
From
martinfowler.com
by Martin Fowler
About a 5 minute read
- Debt taken on deliberately and prudently (a conscious shortcut with a payoff in mind) is fine, and often smart, when you are racing to ship.
- The debt to fear is the reckless kind: messy code from not knowing better, or knowingly cutting corners you cannot afford. That is the interest that compounds.
- Some debt is inadvertent and prudent, you only learn the right design after building it. That is unavoidable and not a failure, so do not beat yourselves up over it.
Open
martinfowler.com →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
The Kano model separates must-be features (whose absence causes real anger) from delighters (whose absence nobody notices yet). That maps cleanly onto your question: a broken core flow fails a must-be need, while a plain UI is just a missing delighter. Use it to sort which parts of your first version can be rough and which absolutely cannot.
From
Wikipedia
10 min read
- Must-be features cause anger when broken but no praise when present
- Polish and delighters are optional early, basic reliability is not
- Sort features by type before deciding what to cut
Open
en.wikipedia.org →
📄 Article
✓ Link checked
India
Free
Advanced
Why we picked it
The CTO of India's largest broker explains how a tiny team scales huge load by optimizing the application before touching infrastructure or rewriting. It is a strong reminder that hitting a limit usually means fixing the slow query, not rebuilding the system. A grounded Indian counterweight to the belief that scale requires a from-scratch rewrite.
From
Zerodha Tech Blog
by Kailash Nadh
15 min read
- Exhaust easy optimizations in the app before rebuilding
- Most bottlenecks are the database, not the platform
- Simple, boring, well understood setups scale further than you think
Open
zerodha.tech →
📄 Article
✓ Link checked
Freemium
Beginner
Why we picked it
Most first 100 users advice is vague. This piece is the opposite: it groups the real cold start tactics into seven concrete plays and names the exact company behind each one, from Tinder pitching sororities in person to Dropbox seeding online communities. Read it as a menu to pick from, not a checklist to run top to bottom, since almost every founder here won just one channel that fit them.
From
Lenny's Newsletter
by Lenny Rachitsky
About a 15 minute read
- The tactics sort into seven repeatable plays: go to users offline, find them online, invite friends, manufacture exclusivity, use influencers, get press, and build a community before launch.
- Most companies got their first users from a single channel that fit their product, so the job is finding your one, not doing all of them.
- Nearly all of it was unglamorous and manual: door to door, one community at a time, personal invites rather than a growth machine.
Open
lennysnewsletter.com →
📖 Book
✓ Link checked
Free
Beginner
Why we picked it
Free to read online, with chapters like "Build Less" and "Half, Not Half-Assed" that name your exact trap. It argues that cutting scope is a feature, and that the version with fewer things done well beats the bloated one. A fast, opinionated read you can skim straight to the chapters that sting.
From
Basecamp / 37signals
by Jason Fried, David Heinemeier Hansson (37signals)
Free online, ~4 hr
- Build half a product, not a half-built product.
- Every feature you add is one more thing to maintain and explain.
- Deliberately underdo the competition on scope.
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 →
