The validation newsletter: publishing an article = one email

You publish an article. Good. Now you need a newsletter. You reopen an editor, you copy, you reformat, you re-proofread. Thirty minutes later you've created nothing new: you've just moved text from one box to another. That double work is exactly what ends up killing your consistency.

The double work is the real reason you skip weeks

When people stop a newsletter, they tell themselves it's an inspiration problem. Wrong. It's a friction problem. Writing the article already costs you 2-3 hours. If the newsletter adds 30-45 minutes of copy-paste-reformat every time, your brain learns very fast to push the deadline back. And a newsletter that ships every other week is no longer a newsletter, it's a sporadic reminder that you still exist.

The trap is that those 30 minutes produce no new value. The reader already has the content: it's on your blog. The newsletter is just a distribution channel. So all the time spent rebuilding it by hand is pure waste — and worse, it's waste that you feel, which makes it demotivating.

The principle: one source format, two outputs

The basic mistake is treating the article and the newsletter as two documents. They're two renderings of the same document. If you write once in a structured format — typed blocks (paragraph, heading, list, callout, code) rather than raw HTML or hacked-together markdown — then a machine can produce the email from the article without you rewriting anything.

Concretely, the article is your source of truth. The newsletter is a projection: you take the blocks, keep the essentials, and adapt the rendering to the email context (fixed width, no exotic CSS, absolute links, a single link back to the full article). You never write twice. You write once, cleanly, in blocks.

• Article in blocks: the source. An array of objects `{type, ...}` — versionable, diffable, reusable.
• Email composition: the machine reads the blocks and generates email-safe HTML (inline tables, no flexbox, text fallback).
• Hook + excerpt: keep the lead p and 2-3 sections, cut the rest with a "Read more" link.
• Canonical link: each email points to the article's URL. One source, no content divergence.

// L'article EST la source. L'email est une projection.
const article = {
  slug: "newsletter-a-validation",
  blocks: [
    { type: "p",    text: "Tu publies un article. Bien..." },
    { type: "h2",   text: "Le double travail..." },
    { type: "list", items: ["..."], ordered: false },
    { type: "callout", text: "...", tone: "tip" }
  ]
};

// La machine compose l'email — mais ne l'envoie PAS.
const draft = composeEmailFromBlocks(article.blocks, {
  maxSections: 3,            // on coupe après 3 h2
  ctaUrl: canonicalUrl(article.slug),
  status: "pending_review"   // <-- rien ne part sans toi
});

Nothing ships without your approval

Full automation is the opposite trap. The day the machine sends on its own, you wake up to an email that went out to 4,000 people with a truncated subject, a broken link, or a joke landing badly in the wrong segment. Automation has to stop one step before sending. It prepares, you decide.

The right default state for a generated newsletter is `pending_review` ("draft awaiting review"). The machine does 95% of the work: it composes, formats, sets the link, prepares the subject. You do the 5% that needs a human brain: you read the subject, check the excerpt cuts off in the right place, click the link once, then approve. Thirty seconds instead of thirty minutes.

Keep editorial control without rewriting

"Approve" doesn't mean "put up with whatever the machine spat out." A good implementation gives you three quick levers, without ever forcing you to reopen the article: choose where to cut the excerpt, rewrite only the subject and the email's intro line (the two elements that deserve an "email" tone different from the blog), and exclude a block that doesn't work in email (a big block of code, for example).

• The subject: it's the only text you actually write by hand every time. 8-10 words, write it yourself, it's what decides the open rate.
• The cut point: a slider or a simple "cut after this block." The machine proposes, you adjust.
• The exclusions: hide blocks that make no sense out of context (long code, internal callout).
• The rest: you don't touch it. It's already the article you approved by publishing it.

To get started: take your next article and force one rule on yourself — you open the email editor only for the subject. The whole body comes from the blocks, automatically. If you catch yourself copying text, your pipeline isn't finished. Consistency isn't about heroic discipline: it's about friction. Remove the copying, keep the approval click, and you'll publish every week without thinking about it.