How do you know when a product is ready to launch?
Your product is ready to launch when at least one real user has a problem you've solved completely enough that they'd be genuinely upset to lose it — not when the feature list feels complete or the design looks polished. Launch readiness is a signal about user need, not product perfection. The faster you can get to that signal, the faster everything else compounds.
The Wrong Benchmark: Internal Comfort
Most founders set the launch bar based on how the product feels to them — the team, the builders, the people who already understand what it's supposed to do. That's the wrong benchmark entirely. Your internal sense of readiness is almost always inflated by familiarity. You know where the rough edges are and you unconsciously route around them. A real user won't.
Paul Graham's observation about user models is pointed here: even founders who are their own target users have an inaccurate mental model of what others actually need, because user needs often shift in response to what gets built. This means no amount of internal review will give you the signal that a single real user session will. The question isn't 'does this feel ready to us?' — it's 'can a stranger accomplish the core task without us explaining anything?'
The practical test: put your product in front of someone who matches your target user, give them a specific task, say nothing, and watch. If you feel an urge to jump in and explain, that's a launch blocker. If they complete the task and express something resembling relief or satisfaction, that's a green light — even if twenty other things are broken.
The 'One User' Threshold
There's a useful minimum viable condition for launch that most founders overlook: can you find even one person who genuinely needs this, can use it today, and would feel the loss if it disappeared tomorrow? Graham's point about B2B startups is instructive here — he advises founders to treat a single user as the mold for their product, fitting that one user's needs perfectly before expanding. If you can't satisfy one person completely, you almost certainly can't satisfy many people partially.
This isn't an argument for perfectionism — it's an argument for specificity. A product that fully solves a narrow problem for one defined user type is infinitely more launchable than a product that partially addresses a broad problem for everyone. Facebook launched to Harvard students only, not because the ambition was small, but because full product-market fit at a small scale is the only honest proof that fit exists at all. A contained, hot fire is more powerful than a warm, diffuse one.
What this means practically: before you announce anything publicly, you should already have a handful of users who were recruited manually, onboarded personally, and are using the product in their actual workflow. If you haven't done that yet, you're not close to ready — and doing it will teach you more in a week than months of internal iteration.
Readiness Is About Signal Quality, Not Feature Completeness
A common mistake is treating launch as a reward for finishing — something that happens after the product reaches a certain level of completeness. But launch is actually a diagnostic tool. It exists to generate the kind of feedback that's impossible to simulate internally. The goal of launching early isn't to acquire users at scale; it's to get feedback at a quality level you can't otherwise access.
The feedback you get from direct engagement with early users — watching them use your product, hearing their actual words when describing the problem, seeing where they get stuck — is categorically different from any other input. It's unfiltered by their desire to be polite in a survey, uncorrupted by the framing of a feature request form, and unmediated by anyone on your team interpreting it for you. Waiting until the product is 'finished' to access this feedback is a strategic error: you're delaying the highest-quality information you'll ever receive.
The practical implication is to set your launch threshold around signal quality, not scope. Ask: 'If we launched today, would users be able to tell us something true and specific about whether this solves their problem?' If yes, launch. If the product is so broken they can't even engage with the core value proposition, fix that first — but only that.
What 'Not Ready' Actually Looks Like
It's worth being concrete about the failure modes on both sides. Launching too late usually looks like a team that has built far more than one use case requires, has optimized UI details that users haven't asked for, and is waiting for confidence that can only come from the market itself. The tell is when launch keeps getting deferred because of internal standards rather than external blocking conditions.
Launching too early looks different: the core action a user needs to take either doesn't work or requires so much hand-holding that you'd need to be present for every session. If you can't let a user try your product without supervising them, you haven't hit the minimum bar yet. The threshold isn't 'perfect' — it's 'self-explanatory enough for the core case.'
Garry Tan has noted that founders often imitate the behavior of large companies — including their indifference to individual users — because it feels more professional. This is exactly backwards at the launch stage. Being small means you can do things that don't scale: manually onboard every user, respond to every support message the same day, hop on calls, watch usage sessions live. These are launch superpowers, not embarrassments. A product is ready to launch the moment you're willing to expose it to that level of direct, unmediated user contact and learn from what you find.
“The feedback you get from engaging directly with your earliest users will be the best you ever get.”
— Paul Graham, source
The one thing to do
Find one real user, put the product in front of them without explanation, and watch — if they can complete the core task and would miss the product if it disappeared, you're ready to launch.
Frequently asked questions
Does the product need to be bug-free before launching?
No. It needs to be functional enough that a real user can complete the core task without your help. Cosmetic bugs, missing secondary features, and rough edges are fine — a broken core flow is not.
How many users do I need before I can call it a real launch?
Even one or two users who use your product in their actual workflow and would miss it if it disappeared is enough to validate that you're solving a real problem. Launch isn't about volume — it's about honest signal.
Should I wait for the product to scale before launching?
No. The tactics that get your first users — manual outreach, personal onboarding, direct support — don't need to scale yet. Launch to a narrow audience first, make it work completely for them, then expand.
What's the single clearest sign a product isn't ready to launch?
If you feel like you'd need to explain or demonstrate the product before letting someone use it, it's not ready. The core flow should be understandable without a guide.
Sources
- gstack: skillify/SKILL.md — Garry Tan
- Do Things that Don't Scale — Paul Graham
- Life is Short — Paul Graham