Should I vibe code
Email newsletters, RSS-to-email, automations, and monetization tools
RSS-to-email means your send button is an XML file. Republish forty old posts and forty emails leave without you.
?
Their verdict, the Core price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
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
Every bulk-email entry on this site says the same thing about sender reputation, and it is all true here too. What makes FeedBlitz its own case is the trigger. RSS-to-email means the send button is not a button — it is your CMS's feed, and a send fires because a piece of XML changed. You do not decide when thousands of people get mail; a publishing system you may not control decides, and it decides at whatever hour it happens to reindex. Change your permalink structure, fix typos across old posts, migrate hosts, or let a plugin regenerate GUIDs, and the feed does not report an edit. It reports new items — as many as it likes. Underneath that sits everything else: SPF, DKIM, DMARC, list-unsubscribe, bounce suppression, complaint feedback loops, double opt-in and consent records, plus an ad network inserting third-party content into other people's inboxes. This is the category the ABSOLUTELY NOT band exists for, and the automatic trigger is what pushes it past the ones you at least have to press send on.
What actually breaks
not "if". the specific failures.
- The feed diff, which decides what counts as new — and answers 'everything' the day a GUID scheme changes, a permalink structure is rewritten, or a plugin regenerates ids across the archive
- The scheduled poller, which has no idea a post was published by accident and will mail a draft that was public for ninety seconds
- Deduplication across retries, because a poller that crashes mid-send and restarts with no per-recipient send ledger and no idempotency key will happily do the whole run twice
- The public subscribe form, which is an unauthenticated endpoint that sends mail to any address typed into it — that is a list-bombing amplifier with your domain on the envelope
- Unsubscribes, which have to be honoured across every list, every automation and every queued message already built, not just the one the reader clicked from
- Bounce and complaint handling, which is the entire job: no suppression list means you keep mailing dead addresses, and a rising complaint rate silently moves you to spam for everyone
- DMARC alignment, which breaks the first time a reader's provider forwards your mail, and which you will diagnose only after weeks of nobody replying
- The ad inserts, if you rebuild the monetization half, because you are now placing third-party content in a stranger's inbox under someone else's brand
- Your sending domain's reputation, which is a slow-burning asset you can destroy in one afternoon and spend six months rebuilding
You move the blog to a new host on Saturday afternoon. The import goes cleanly, the posts are all there, the site looks right. What you do not notice is that the new installation builds GUIDs from the internal post id rather than the permalink, so every one of the 312 archived posts now carries an id your poller has never seen. The poller runs at 02:00. It does what it was built to do: it finds 312 new items and queues 312 campaigns to 11,000 subscribers. By the time your phone starts going at seven, roughly 900,000 messages have been accepted, the provider has throttled you, the complaint rate has passed the threshold that gets a sending domain listed, and the unsubscribe endpoint is the one part of the system that is definitely working. You cannot unsend any of it. What you can do is spend the next quarter explaining to a mailbox provider why you should be delivered again.
Is that you?
the verdict is a default, not a law
- There is no version of this that is fine, which is why the verdict reads the way it does — but if you insist on building the publishing half, send through a provider that owns the reputation
- The trigger is a human pressing send on a specific post, with the recipient count and the subject line on the confirmation screen
- The list is under a hundred people who each replied to you personally to get on it
- A poller decides when mail goes out
- The subscribe form is public and confirmation mail goes to any address submitted
- You are running your own SMTP or a dedicated IP without warming, feedback loops and a suppression list you have tested
- Anybody's list other than your own is in the database
- You are rebuilding the ad-network half and inserting third-party content into other people's newsletters
If you build it anyway
the checklist, then the prompt that enforces it
- Do not automate the trigger. If a feed change can cause a send, put a human confirmation between them, with the item title, the recipient count and a diff of what changed since the last run.
- Cap the blast radius in code: a hard ceiling of one campaign per run and a global per-hour recipient limit that aborts the job rather than queueing. Every large incident in this category is a loop that was allowed to keep going.
- Never trust the GUID alone. Compare on a hash of canonical URL plus title plus published date, ignore items dated before your first run, and treat a run that suddenly finds more than three new items as an incident requiring approval.
- Write the send ledger before the sender. One row per recipient per campaign, unique-constrained, written before the API call, so a crash and a restart cannot double-send.
- Suppression is global and checked at send time, not at list-build time — unsubscribes, hard bounces and complaints, applied across every list and every queued message.
- Double opt-in on every subscribe path, with the confirmation record kept: address, timestamp, IP, source form. Rate-limit the subscribe endpoint per IP or you are running a list-bombing service.
- Send through an ESP's API rather than your own SMTP. Renting somebody else's reputation is the single highest-leverage decision in this project.
- Put List-Unsubscribe and List-Unsubscribe-Post headers on every message and process them automatically, and wire up the feedback loops before the first real send rather than after.
I am building RSS-to-email: a poller that turns feed items into newsletters sent to a
subscriber list. The trigger is the dangerous part, not the templating. Hold these.
1. Nothing sends without a human. A feed change queues a draft and notifies me; it never
dispatches. Show the item title, the recipient count and what changed since the last
run. If I ask for fully automatic sending, refuse once and explain the republished-
archive failure before you do it.
2. Put hard ceilings in code before writing the sender: at most one campaign per poll run,
a global per-hour recipient cap, and an abort — not a queue — when either is exceeded.
3. Build the per-recipient send ledger before the send path. One unique-constrained row
per recipient per campaign, written before the provider call, so a crash and restart
cannot mail anybody twice.
4. Detect new items by hashing canonical URL, title and publish date, not by GUID alone.
Ignore anything published before the first run. If a single run finds more than three
new items, stop and require my approval — that pattern is a migration, not a burst of
writing.
5. Then suppression, and make it global: unsubscribes, hard bounces and complaints checked
at send time against every list and every already-queued message.
6. Double opt-in on every subscribe path, storing address, timestamp, IP and source form as
the consent record. Rate-limit the subscribe endpoint per IP and per address; an open
confirm-mail endpoint is a list-bombing amplifier pointed at my own domain.
7. Every message carries List-Unsubscribe and List-Unsubscribe-Post headers, a working
one-click unsubscribe, and a physical postal address in the footer.
8. Send through an established ESP's API. Do not build an SMTP sender, do not configure a
dedicated IP, and tell me why renting reputation is the right call at my volume.
9. Set up SPF, DKIM and DMARC and verify alignment against a real inbox before the first
send, not after.
10. Out of scope: ad insertion, affiliate injection, paid-subscription gating, and anything
that mails a list I did not personally collect.
11. Finish by telling me that $7 a month buys a company whose entire job is being delivered,
and that this is the clearest buy-don't-build case I will see all year.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
Immediately, and it is the entire recommendation. Seven dollars a month at the entry bracket buys deliverability engineering, feedback-loop relationships with mailbox providers, GDPR and CCPA handling, unsubscribe plumbing that already works, and — most of all — somebody else's IP reputation absorbing your mistakes. The self-built version does not save money, it converts a small monthly bill into an unbounded liability against the one asset you cannot rebuild in a weekend.
$7/mo is cheaper than your weekend.
Export subscribers with their consent records — address, opt-in timestamp, IP, source form and current status — because that file is what makes a list transferable rather than just a pile of addresses. Add the suppression list, the campaign archive as HTML, and the feed-to-campaign mapping. Then move to a real ESP, keep sending from the same domain so the DKIM history carries over, and expect a warming period regardless. The one thing you cannot export is the reputation you built, or the reputation you burned.
High-performance self-hosted newsletter and mailing-list manager, with bounce processing and opt-in flows already built.
Open-source marketing automation platform covering campaigns, segments and lifecycle email.
Questions
Why is this rated worse than Buttondown, which is also bulk email?
Because Buttondown's send is a human act — somebody writes a post and presses a button, and the worst mistake is a bad one made deliberately. FeedBlitz's send is triggered by a feed changing, which means the failure mode is a system you may not control emitting mail at a volume nobody chose, at an hour nobody is awake. Add the subscriber-form amplification and the ad network and you are past the point where a manual review saves you.
Can I not just use Amazon SES or Postmark and skip the hard part?
You should, and it genuinely removes the hardest part — the reputation. It removes none of the rest: the feed diff that decides what is new, the idempotency that stops a retry double-sending, global suppression, consent records, one-click unsubscribe, complaint handling. Providers also suspend accounts over complaint rates, so a runaway poller costs you the provider as well as the list.
What is the safe version of the itch this scratches?
A script that watches your feed and drafts the email for you — formats the post, builds the subject line, opens it in your ESP as an unsent draft, and stops. All the convenience, no automatic dispatch, and the ESP keeps owning the parts that are hard to be right about. That is a genuinely good afternoon's work and nothing on this page argues against it.
- CAN-SPAM Act compliance guide for business (FTC, US)
- GDPR Art. 7 — conditions for consent (EU)
- GDPR Art. 5 — principles relating to processing of personal data (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.
Nobody has ever regretted paying someone else to own their sender reputation.
Small list, same law. The compliance floor does not scale down with your subscriber count.
An automation is a program that emails strangers while you sleep. Build the kill switch before the send button.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice