Substack for an email course: what to check first

A post is published; a lesson is delivered

A publishing platform puts the post at the centre. One piece is written, it goes to everybody subscribed at that moment, and it stays at a URL afterwards. That is an excellent shape for a newsletter and it is the opposite of what a course needs, which is one fixed series delivered to each person from the day that person subscribed.

So the first thing to establish on Substack is whether a per-reader sequence exists as a shape at all, what starts it, and what each delay after the first is counted from. That one answer decides the rest of the evaluation, because a course assembled out of scheduled posts serves the people already subscribed in the week it runs and reaches nobody who arrives in April.

The second thing to establish is what a lesson is once it has been sent. Where the default unit is a post, it usually leaves a page behind as well as an inbox copy, so day four is readable without day one and the course stops being something somebody joins in order to receive. That is a legitimate way to publish a course. It is a different promise from the one most course landing pages make, and it is worth choosing rather than inheriting.

Where a new reader came from, and what they agreed to

Platforms of this kind grow partly through each other: readers are recommended from one publication to the next, and a subscription can begin on a page you did not write. That is a real source of audience, and it is also where the consent question gets interesting, because what the reader agreed to was written by somebody else.

Ask three things about any such route. What was the arriving reader shown, are they asked to confirm before the first lesson, and does the course sequence start for them automatically? Then ask the plain version at every other door: an import, an address added by hand, an API call, an embedded form on your own site. A course is only as clean as the dirtiest door onto it.

The unsubscribe question has the same shape. Ask what an unsubscribe reaches: the course, the publication, or everything the account would send that person. Somebody who leaves on Tuesday and hears from you on Wednesday reports the message rather than clicking a link that visibly did not work the first time.

What leaves with you, and what stays behind

The most valuable thing a writer owns is the relationship with the people who read them, and on a publishing platform that relationship is stored in three places. The addresses are one. The consent record — what somebody agreed to, when, and from where — is the second, and it is the part that answers a complaint two years later. Everybody who unsubscribed, bounced hard or complained is the third, and it is rarely offered beside the export.

Ask for all three by name while the account is open. Then ask what a published lesson carries with it if the publication moves: the text, the URL, and the links other people have already made to it. A page that has been collecting links for two years is worth something real, and where it lives decides who that something belongs to.

The last item is the domain. Ask what has to be added to DNS before mail leaves on one you own, and what goes out if nothing is added. Mail on a shared domain starts faster and keeps your own complaint rate inside a figure only the platform can see, which is a fair trade for a first course and a ceiling for a list that eventually wants to move.

If you already write on Substack, test these four things first

Writing there already is the strongest argument for keeping the course there: one archive, one subscribe page, one place a reader replies to. Two addresses and two days will settle the timing, which is the only answer able to end the evaluation on its own.

Four tests, in the order that finds problems earliest:

• Subscribe today with one address and tomorrow with a second. The second should receive day one.
• Look at what a lesson leaves behind besides the message, and open that in a browser while logged out.
• Read what a reader arriving through a recommendation is shown before they receive lesson one.
• Unsubscribe on day three with the mail client’s own button, then publish an ordinary post and see whether it lands.

What no dashboard shows

One failure stays invisible from inside any account: the send that returns nothing after the mail provider already accepted the message. Sent late is an inconvenience; sent twice is a complaint, and the shape that prevents it is a uniqueness rule in a database rather than a line somebody remembered to write.

And the limit of a page like this one. Everything above is phrased as a question because everything above moves: a platform ships every week, and a sentence stating what it does today is a sentence that goes wrong with nobody noticing. A question stays useful after the software has been rebuilt twice.