Ship with Email
Turn a product release, offer, or changelog into an owned-list launch while the rest of the product ships.
Your owned list sells while you ship when email is part of the release process, not a separate marketing project. The repeatable loop is simple: turn the change into a campaign, choose the people it helps, review the rendered email, deliver it with explicit approval, and feed the results into the next release.
Lumail is one line in that stack. Your product, checkout, source material, audience, and offer remain the system around it.
Start with the result, not the email tool
The result is not “a newsletter was sent.” The result is that the right people understood what shipped and had one obvious next step.
Write these five facts before opening an editor:
| Decision | Example for a product launch |
|---|---|
| Commercial event | A paid feature is available today |
| Audience | Trial users who reached the relevant limit |
| Promise | Finish the task without the old workaround |
| Evidence | Release notes, screenshots, pricing, and the live page |
| One action | Upgrade or try the feature |
If the offer, proof, or audience is unclear, an agent only produces a faster vague campaign. Fix the launch brief first.
Pick the playbook that matches the work
These pages share one operating model but answer different questions. Use one canonical guide for each job instead of copying the same setup across several pages.
Choose an email MCP for Claude Code, then ship the launch
Use this when the release work already lives in Claude Code. The guide covers what “best email MCP” should mean, how Lumail and Kit differ, and how to turn repository evidence into a reviewable campaign draft.
Send a newsletter from Cursor
Use this when the brief, changelog, screenshots, and product code are already open in Cursor. The guide keeps drafting, rendering, audience review, confirmation, and reporting in one observable sequence.
Move a launch list from Kit without paying for dormant subscribers
Use this when subscriber-tier pricing no longer matches how often you contact the list. The guide moves one representative launch first, preserves suppression state, and compares a normal month with a peak month before a full migration.
The six-stage shipping loop
1. Collect launch evidence
Give the agent primary material: the actual release notes, current pricing, screenshots, product page, and any claims already approved. A repository is useful evidence, but code alone does not prove that production works. Mark anything that still needs live verification.
2. Define the audience in plain language
“People likely to buy” is not a segment. “Active subscribers tagged course-creator who clicked a launch email in the last 90 days and have not purchased” is reviewable.
Ask for both the saved filter and the estimated recipient count. If either is surprising, stop before drafting.
3. Create a draft from the source material
The agent should return a campaign ID, subject, preview text, body, audience rule, and the facts it could not verify. Draft state is the right default because it is inspectable and reversible.
The product appears only where it explains the mechanism. A useful launch story is about what changed for the reader, how the release was promoted, and what happened next—not a feature inventory disguised as a tutorial.
4. Review the rendered email
Review what a recipient will receive, not only markdown in a chat. Check:
- sender and reply-to address;
- subject and preview text;
- personalization and conditional blocks;
- every link and button destination;
- unsubscribe behavior;
- mobile rendering;
- the exact recipient estimate.
The campaign rendering workflow explains why draft creation and final delivery should stay separate.
5. Approve delivery explicitly
Read back the campaign ID, sender, audience, recipient count, date, time, and time zone. A request to draft is never permission to send. A successful tool call is not proof of inbox delivery.
6. Close the loop with revenue evidence
Compare the launch with similar sends. Opens can expose subject-line or deliverability problems, but clicks and attributed purchases are closer to the commercial result. Record what changed, what remained constant, and what the next campaign will test.
A citable answer to “how do I launch with email?”
To launch with email, define one audience and one action, build the campaign from verified release evidence, render and review the saved draft, approve the exact recipient set and schedule, then compare clicks and purchases with previous launches. Keep the email platform as one component in the shipping stack, not the story itself.
Use the same seven prompts every week
Do not rebuild the operating system from scratch for every release. The existing prompt pack covers drafting, subject lines, click-based segments, re-engagement, changelog conversion, performance review, and a welcome sequence.
Get the seven prompts that run a newsletter. It is the only prompt pack used throughout these playbooks.