Before Readers Scan Your Newsletter, Add How I Make This
For early founders, visible process beats score-chasing: scan drafts, state your method, and choose a detection setting with a reason.
Your first hundred will not care about your growth loop. They will care whether the words in your inbox feel like a person made them. If you are using a newsletter as a trust channel, the new scanner changes the default. Substack now gives readers a scan button powered by Pangram.
The tool can check posts, notes, replies, and comments. It only applies to text longer than 100 words. The result stays private to the person who asks. That privacy matters. A reader can test your work without turning it into a public dispute.
Pangram estimates that up to 40% of text on certain social platforms is AI-generated. That number does not prove your newsletter is suspect. It does mean readers may assume suspicion until you make your method visible.
Substack's AI-detection feature has divided its community. For a founder with no distribution yet, that division is useful. It shows what your first readers are already asking: did a human sit with this idea long enough to make it useful?
Scan your own drafts before your readers do
Run the detector on unpublished drafts. Done looks like a short list of pieces you would not send if a stranger could see the scan. Do not chase a clean score. Find the places where your voice became generic advice.
Start with the post you most want your first hundred to read. Check the intro, the middle, and the close. If a paragraph sounds like it could appear in any newsletter, rewrite it with your actual constraint, your actual customer, or your actual mistake.
Then read your recent posts as if you were the reader with the button. Read them quickly. Mark the sentences that feel interchangeable. Those are the places where a reader might pause.
Keep a plain list of the changes you make. Not for a report. For your own memory. When a reader asks why a section changed, you can point to the edit instead of guessing.
Warning: do not treat the scan as a quality score. A low flag can still be boring. A high flag can still be useful. The scan tells you where a reader might pause. It does not tell you whether the idea earns trust.
Write the one-line process note
Add a process note labeled How I make this. Keep it to one line. Done looks like a sentence a skeptical reader can repeat: the writer uses notes, interviews, and failed attempts, then edits for a specific reader.
Skip the manifesto, the tool list, and the argument that machines are bad. The note should answer one question: what human process made this piece? If you use a model to draft, summarize, or clean grammar, say so plainly.
A weak note says the writer uses research. A stronger note says the writer interviews customers, drafts from notes, and cuts every sentence that does not serve a first-time reader. The line should be specific enough to be falsifiable. The reader is not asking for purity. They are asking for accountability.
Choose your detection setting with a reason
Choose whether to keep the scan available or disable it, and write a short reason. A finished note reads like a one-sentence add-on under your process line. Keep scanning on because readers should test the process, or turn it off because the tool misreads technical writing.
If you keep it on, your reason should be about reader trust. If you turn it off, your reason should be about a known limitation of the tool. Do not hide behind the idea that everyone uses machines. It is a weak answer. Your first hundred are watching how you handle a minor issue.
Write the reason before you publish the next issue. If you cannot say it plainly, the setting is probably a mood, not a policy.
Flag scans you consider incorrect. Do this quietly, without a public rebuttal. A calm correction is more useful than a public argument. Do not try to win a debate about the tool. Make your process visible enough that the tool matters less. Then send the next issue with the note attached.
