Don't publish that

You know the feeling. You've been working on something — a landing page, a small site, a project you've been meaning to get live for weeks — and the thing is finally in a good-enough state. You've got a cursor hovering over the deploy button. You should just hit it. The universe rewards shippers. Done is better than perfect. Stop tweaking and get it out there.

Don't publish it. Not yet.

This is the essay against the religion of shipping that dominates software culture. It's short, because the argument is simple: one more day almost always makes the thing meaningfully better, and you rarely regret the extra day.

What one day does

A day is enough to notice things. You close the laptop, go for a walk, do something else, come back, and suddenly the second paragraph of your about page sounds wrong. You change it. The page is better. Now the first paragraph sounds wrong in comparison, so you change that too. Now the hero headline, which you thought you loved, is clearly not the right sentence. You change it. Ten minutes of editing, a measurable improvement.

That cycle only happens if you give yourself distance from the thing. You can't edit with fresh eyes if your eyes aren't fresh. Shipping prematurely is what happens when you confuse “I can't see anything else to fix” with “there's nothing to fix.” Those are very different states.

The ship-fast argument, rebutted

The standard argument against what I'm saying is that you should ship the minimum viable version and learn from real users. This is good advice for a team of twenty building a SaaS product, and bad advice for a single person making a personal site. The feedback loop you actually care about isn't “do my users like it?” — it's “do I?” And that feedback loop takes distance, not traffic.

It's also a defensive argument. “Ship fast and iterate” lets you avoid the scarier question of whether the thing is good. You can always fix it later. You can always change it based on feedback. You don't have to sit with the uncomfortable question of whether you're proud of it. Shipping prematurely is often a way to skip the judgment.

What to do instead

Sleep on it. Seriously — the oldest writing advice there is, applied to design. When you think the thing is done, save it, close the laptop, and come back the next morning. You will find three things to improve in the first five minutes. Fix them.

Then show it to one person. Not ten. One. Ideally someone who isn't in your direct circle of feedback. Watch their face while they look at it. Don't explain anything. Whatever their first reaction is tells you something you couldn't have learned by staring at it alone.

Then sit with it one more day. This is the hardest step, because you will want to ship. Resist. The compound returns of one more editing pass are enormous and invisible until you've done them.

The exception

There's one exception to all of this, which I'll name to be honest: if you've been sitting on something for months because you can't bring yourself to ship it, this essay isn't for you. You're stuck. The correct advice for stuck is the opposite — ship now, it will never be ready, you have to let it go.

But that's a different disease. If you've been working on something for a day or a week and you're ready to hit publish tonight, sleep on it instead. The project will benefit. The thing that shipped tomorrow, with fresh eyes behind it, will be better than the thing that shipped tonight.

The universe does not, in fact, reward shippers. The universe rewards the people who sat with their work until it was the way they wanted. That's a slower and quieter and less Twitter-friendly virtue than moving fast. It's also the one that actually makes the work good.

Go to bed.