Should Your Side Project Have a Newsletter? A Straight Answer

The standard advice is to start a newsletter alongside anything you build. Own your audience, don't rent it from a platform, and so on. The advice is sound in principle and, for a lot of side projects, wrong in practice — because it quietly assumes you have spare capacity you almost certainly don't.

A newsletter is a recurring commitment attached to a project that already competes with your job and the rest of your life. It's worth being deliberate about whether you want one.

The question isn't whether newsletters work — they demonstrably do. It's whether this project, at its current stage, benefits from one more than it benefits from the same hours spent building.

When it genuinely helps

Your project has a slow decision cycle. If someone might plausibly want your thing in six months but not today, you need a way to stay in contact until then. That is precisely what an email list is for, and nothing else does it as well.

You're pre-launch. A list of people who asked to hear when you ship is the single most useful asset you can have before shipping. It also functions as evidence — a hundred signups from a landing page tells you something real, and zero tells you something more useful still.

The project is the writing. If what you're building is an audience, a body of work, or a reputation in a field, the newsletter isn't a marketing channel for the project. It is the project.

You need users to come back. Products that people use once and forget benefit enormously from a legitimate reason to return. A monthly note about what changed does this without any of the unpleasantness of notification spam.

When it's a distraction

You haven't got anything to say yet. Writing about building a thing is a well-known and very comfortable substitute for building it. If your project is three weeks old and unfinished, the newsletter is procrastination wearing a productive hat.

Your product is a one-time transaction. Some things people use once and never think about again, and that's fine. An ongoing relationship isn't always the right shape.

You already can't keep up. Adding a weekly deadline to a project you touch on alternate Sundays produces a dead newsletter, and a dead newsletter is worse than none — it's public evidence of abandonment sitting on your homepage.

You're doing it because you were told to. Not a joke. A newsletter written out of obligation reads exactly like one, and the people who signed up can tell.

The low-effort version that actually works

If you land on yes but the commitment worries you, there's a shape that survives contact with a busy life.

Promise irregularity, deliberately. On your signup form, say “occasional updates — roughly monthly, sometimes less.” You have now made a promise you cannot break. Nobody unsubscribes because an occasional newsletter was occasional, and the guilt that kills most side-project newsletters never arrives.

Write from a changelog. Keep a running note of what you shipped. When it's long enough to be interesting, that's an issue. This inverts the usual problem — you're never staring at a blank page, because the raw material accumulated as a by-product of the work.

Keep issues short. Three hundred words about something you actually built beats fifteen hundred words of manufactured insight. Short issues also get read, which is the point.

Send to ten people without embarrassment. A list of ten that includes two people who might use your thing is worth more than a thousand strangers. Everyone's list started this size.

The alternative nobody mentions

There is a middle option between a newsletter and nothing, and it suits a lot of side projects better than either: collect email addresses without committing to send anything on a schedule.

A form that says “leave your email and I'll tell you when this is ready” is not a newsletter. It's a notification list. There's no cadence to maintain, no guilt when you don't write, and the asset — a list of people who raised their hand — is identical. You can convert it into a newsletter later if you find you have things to say, and most people never need to.

The one obligation this carries is that you have to actually use it. A notification list you never mail is worse than useless, because when you finally do send something two years later, nobody remembers signing up and you collect a run of spam complaints for your trouble. If more than about six months pass, reintroduce yourself in the first line and expect some attrition.

We'd suggest most people start here. It costs nothing, it's reversible in the direction that matters, and it removes the main reason side-project newsletters fail — which is that they were a commitment made before there was anything to commit to.

The setup, minimally

Enough to be functional without becoming a project of its own.

• A platform with a free tier that lets you export. Ignore everything else about it for now — our platform guide covers what matters when it starts to.
• Your own domain for sending, with SPF, DKIM and DMARC configured. One afternoon, and it prevents the single most common failure — your issues quietly landing in spam.
• Double opt-in on. Small lists especially can't absorb the deliverability damage from a few bad addresses. The reasoning is here.
• A form on the page people actually land on. Not a separate subscribe page nobody visits. If your project lives across a landing page, a docs site and a GitHub README, an embeddable subscribe widget lets you put the same form on all of them with one snippet.
• A real reply-to address that you read. On a small list, the replies are the entire point.

How to stop without it being awkward

Worth planning for, because most side projects end and almost nobody handles the newsletter part gracefully. The usual approach is to simply stop sending, which leaves people subscribed to something that no longer exists.

Send a final issue instead. Say the project is winding down, say what happened, and tell people whether the list is being retired or whether you'll use it again for something new. Ask them to unsubscribe if the latter doesn't appeal. It takes twenty minutes, it's consistently the best-received issue people send, and it leaves you with a small list of people who'd genuinely like to hear what you build next.

What to write when you've shipped nothing

The common stall. A few things that are legitimately interesting even when progress is slow:

A problem you hit and how you solved it. A decision you reversed, and why — these are consistently the best-received issues anyone writes. A thing you learned about your users that surprised you. What you decided not to build. Even a short honest note saying the project has been quiet because life happened is fine; people respond to it far better than to silence.

What not to write: milestone announcements with no substance, roadmaps you won't hold to, and anything that reads as an announcement of an announcement.

The honest summary

Start a newsletter if you have something to say and someone who'd want to hear it. Don't start one because a growth post told you to. And if you do start, set expectations low enough that you can meet them on your worst month — that single decision is what separates the newsletters still running in a year from the ones with four issues and a gap.

If you're going ahead, our step-by-step guide to starting a newsletter covers the full path, and the guide to getting more signups covers what to do once the form exists.