On not launching, and shipping instead

I used to organise weeks around a launch. I have stopped. The last three projects had no launch day at all, and did better than the ones with fireworks.

The word launch is doing damage to a lot of small projects, mine included. I want to make the small case, in this log, for not launching at all — and for what to do instead.

What a launch actually costs

A launch is not free. It costs the two weeks before it (writing the post, cropping the screenshot, prepping the tweet thread, "warming up" the audience you don't have), the day itself (refreshing dashboards), and the two weeks after it (deflating). That is a month of your working time spent on marketing an object that, on the day of the launch, mostly does not yet work in the way the marketing describes.

For a small project with no team, this is often the worst possible allocation of the founder's time. Because the product is not yet good enough to hold the attention the launch briefly buys. Because the founder is now exhausted right at the moment they need to be answering support emails from confused early users. Because everyone who tried it on launch day now has an opinion about a version of the tool that will not exist in three weeks.

Launch day is a fireworks show. What you actually needed was a slow morning fire that stays warm for a year.

What I do instead: continuous, quiet publishing

For the last three tools I have followed the same pattern.

1. Put the site up as soon as the tool does the first useful thing, without telling anyone. Get indexed. Fix the obvious bugs.
2. Write one honest, ordinary post about the specific problem the tool solves, in a place where people with that problem actually spend time (a niche forum, a small subreddit, a mailing list). No "launch" framing. Just: here is a thing, here is what it does, here is the URL.
3. Do that again, in a different place, two or three weeks later. Then again.
4. Respond to every email personally, in a warm and short tone, within a day.
5. Ship a small visible improvement every week and mention it, briefly, in the changelog on the site.

The compound effect of this is quiet and steady. There is no "launch day" spike, but there is also no "post-launch trough." Growth looks less like a shark fin and more like a slow ramp, and the founder still has energy left in month three.

The changelog is the marketing

Once you stop having a launch, the visible thing you have instead is the changelog. This is worth taking seriously. Not as an internal document — as a public artefact that says, week after week, "this thing is alive." Every real prospective customer I have ever won has, at some point in their evaluation, opened the changelog and scrolled down.

Two rules I use for changelog entries:

• Every entry ends with a plain "why" — one sentence about the user problem it addresses. Nobody outside the team cares that we bumped a library.
• No hyperbolic language. "Improved" is worth more, over time, than "supercharged." The changelog is trust, not advertising.

What replaces the launch high

The hardest thing about not-launching is that there is no dopamine cliff. You do not get the fifty tweets, the "congratulations" DMs, the temporary sense that you exist in the timeline. You get, instead, an email from a stranger who tried the tool on a rainy Wednesday, said "this is nice, thank you," and paid. That is a smaller emotion. It is also, I think, a more durable one, because it is attached to something real about the work rather than something performative about the moment.

When to actually launch

There is a version of launching that still makes sense: when a specific big change is genuinely worth an announcement, and the audience already exists. A v2 that overhauls the UX for existing users. A large new feature that a subset of your users have been waiting for. A price change, well flagged. That is announcement, not launch. It is a note to people who already know you. It does not need fireworks — a plain email and a changelog entry will do.