The second half of "launch fast" is in a different essay, and it explains why nobody launches

I went looking for the exact wording of Paul Graham's "launch fast" last week and found something that changed how I read it.

The instruction is in Startups in 13 Sentences. The reason most people quote for it — you learn what you should have been building — is also there.

But the sharper argument is in a different essay entirely, The Hardest Lessons for Startups to Learn, from April 2006:

> "Perhaps the most important reason to release early, though, is that it makes you work harder. When you're working on something that isn't released, problems are intriguing. In something that's out there, problems are alarming. There is a lot more urgency once you release. And I think that's precisely why people put it off. They know they'll have to work a lot harder once they do."

That last line is the part I keep coming back to. He isn't saying people are perfectionists. He's saying they postpone because they know what comes after.

Which reframes the whole thing. Not shipping isn't a skill problem or a motivation problem. It's a rational response to the fact that launching creates an obligation, and not launching doesn't.

Here's what I think has changed since 2006 and what hasn't:

Building got cheap. A working skeleton takes an afternoon now. That was the half Graham wasn't even talking about, and it's solved.

The half he was talking about — the moment a problem stops being intriguing and starts being alarming — is untouched. An agent writes your code. It doesn't get nervous when something breaks. So cheap building doesn't give us more finished projects. It gives us more half-finished ones, faster.

The thing that made me post this: I found the identical test in an enterprise context, twenty years later. 8090.ai lists five criteria for what counts as a "software factory" rather than a tool, and the fifth is accountability — when the output is wrong, "someone specific answers for it, fixes it and eats the cost." They call the usual alternative, "the output is provided as-is and verification is your problem," disqualifying.

Enterprise version: who takes the call when it breaks in production.

Solo version: who notices if I skip day 4?

For most of us the honest answer is nobody. No colleague, no standup, no deadline that affects another human. And that's precisely why the postponing is rational.

I don't have a clean answer to this. Reminders don't do it — a reminder from a system that gives up nothing isn't an obligation, it's a notification. Public accountability threads work for some people and turn into performance for others.

So the question I actually want to ask here:

For those of you who did ship something on the side — what was the thing that made postponing cost you something? A person, a deadline, money already spent, a public promise? Or did you just find a week where you felt like it?

I'm asking because I suspect the honest answer for most is the last one, and I'd like to be wrong.