Should I vibe code
Send a low-volume newsletter and transactional messages with clear consent records
Transactional and marketing mail have different rules, and mixing them poisons both.
?
Their verdict, the Starter price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-03.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Running your own sender means owning IP warm-up, suppression lists and the difference between mail people asked for and mail they did not. That distinction is legal, not technical.
What actually breaks
not "if". the specific failures.
- Marketing and transactional mail leaving on the same IP, so a promotional blast takes your password resets down with it
- A transactional template that quietly acquires a marketing footer, and with it a legal obligation it does not meet
- Consent records you did not keep, on the day someone asks where you got their address
- Bounce handling that retries a hard bounce, which is how a reputation goes from poor to blocked
- A password reset that arrives forty minutes late because it is queued behind eleven thousand newsletters
The launch email went to the whole list at nine. By ten, your support inbox is filling with people saying the reset link never arrived. It did not: the campaign and the transactional mail share a sending identity, the campaign drew enough complaints to tip your reputation, and the provider is now deferring everything from that IP — including the one message that lets a customer back into their account. The marketing email you could have resent tomorrow. The reset is the one they needed tonight.
Is that you?
the verdict is a default, not a law
- It sends transactional mail only, through a provider API, on a separate sending identity
- The recipients are all your own users acting on their own request
- Nothing in it is promotional, and nothing ever will be without a new decision
- The same code path sends both marketing and transactional messages
- You cannot produce a consent record for every address on the list
- Bounces and complaints are not processed automatically
- Anyone's ability to log in depends on mail you also use for campaigns
If you build it anyway
the checklist, then the prompt that enforces it
- Two sending identities, two subdomains, two API keys — transactional and marketing never share reputation. This is the whole point of the entry.
- Transactional mail carries no promotional content. The moment a footer sells something, it is marketing and the rules change.
- Process bounces and complaints via webhook and suppress permanently. Never retry a hard bounce.
- Store consent per address: timestamp, source, IP. Imports without it get rejected, not defaulted.
- Unsubscribe on every marketing send, one click, plus List-Unsubscribe headers. Transactional mail does not get one and does not need one.
- Queue transactional mail on its own path with its own priority, so a campaign can never delay a password reset.
Before you write any code that sends email, apply these and push back if I ask you to break them. 1. Ask me first whether this sends marketing mail, transactional mail, or both. If both, build them as two separate senders with two subdomains, two API keys and two queues. Do not let me share one path 'for now'. 2. Transactional messages must contain no promotional content of any kind. If I ask you to add a product mention to a receipt or a reset email, refuse and explain that it reclassifies the message and drags CAN-SPAM and GDPR consent rules onto it. 3. Send through an established provider's API. Do not configure an MTA. 4. Transactional mail gets its own queue with its own priority. Show me the code path proving a ten thousand recipient campaign cannot delay one password reset. 5. Wire bounce and complaint webhooks before the first send. Hard bounces suppress permanently and are never retried. Complaints suppress immediately. 6. Every marketing recipient has a stored consent record: timestamp, source, IP. Any import lacking those fields fails rather than defaulting to 'subscribed'. 7. Every marketing send carries a working one-click unsubscribe plus List-Unsubscribe and List-Unsubscribe-Post headers, honored within the same send. 8. Set up SPF, DKIM and DMARC on both subdomains and verify DKIM alignment, not just signature presence. 9. In the README, state which subdomain is which and warn that merging them later will take the transactional mail down with the marketing mail. Then suggest I just pay the $9.
That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
At $9 a month this is the cheapest entry in the ABSOLUTELY NOT band, and what you are buying is the separation of the two mail streams plus someone else's bounce processing. The build is not hard; the consequence of getting the split wrong is that people cannot log in.
$9/mo is cheaper than your weekend.
Keep the subscriber list and its consent records exportable as CSV from the first day, and keep transactional templates in the repo rather than in a provider UI. Moving providers should be a DNS change and an API key, not a re-consent campaign.
Mature open-source newsletter and mailing-list manager.
Questions
Is one shared IP really that fragile?
Yes, and the asymmetry is the problem. Reputation takes months of consistent, wanted mail to build and a single campaign with a bad list to lose. Providers do not distinguish 'this message is important' — they see a sending identity that generates complaints and they defer everything from it.
Where exactly is the line between transactional and marketing?
The practical test is whether the recipient triggered it and expects it right now. A receipt, a reset, a shipping notice: transactional. Anything sent on your schedule to promote something: marketing. Mixed-purpose messages are treated as marketing, which is why a promotional footer on a receipt is a legal change, not a design change.
- CAN-SPAM Act: A Compliance Guide for Business (FTC)
- GDPR Art. 7 — conditions for consent (EU)
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
The unsubscribe link is the regulated part, and it is the part you will implement last.
Sending bulk email is 5% code and 95% not getting your domain blacklisted forever.
Your reputation as a sender is an asset you can destroy in one bad loop and never rebuild.
last reviewed 2026-08-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice