Should I vibe code
Manage a small subscriber list and send compliant campaigns through a hosted provider
The cheap plan routes through your own AWS account. So does the sending pause, the morning after the import.
?
Their verdict, the Pro 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
EmailOctopus is the cheapest possible answer to "how do I send a newsletter", and the cheapest tier of it is literally a control panel bolted to your own Amazon SES account. Which means the DIY version is not a fantasy — it is the same architecture minus the people who watch the metrics. And the metrics are the entire product. AWS holds you to a bounce rate under 5% and a complaint rate under 0.1%; cross those and SES puts your account under review, and keeps going until sending is paused. Not paused for the newsletter. Paused for the AWS account, which is also the one running your password resets, your receipts and your production alerts. Layer on top of that the parts of bulk email that are law rather than engineering — an unsubscribe that has to work on the first click and be honoured within ten business days, a physical postal address in the footer, a consent record you can produce for every address on the list — and the honest answer is that this is one of the few categories where a bug is not a bug report. It is a permanent change in whether your domain reaches inboxes.
What actually breaks
not "if". the specific failures.
- The unsubscribe link, which has to work on the first click, without a login, and be honoured on the send that is already queued — not just the next one
- Bounce and complaint handling: SES publishes them to SNS and expects you to act on them. Nothing forces you to subscribe to that topic, and nothing warns you that you never did
- The signup form, the day a bot finds it and pumps ten thousand fake addresses through it. Every confirmation email goes out under your domain and every hard bounce lands on your sending reputation
- Retries. A send loop that crashes at subscriber 4,000 and gets restarted from the top mails the first 4,000 people twice, and there is no version of that you can take back
- Suppression. SES keeps a global suppression list, your app keeps its own, and the address someone unsubscribed from last year is back in the CSV they re-imported this morning
- Consent provenance: where each address came from, when, and what they agreed to. Nobody records it until a complaint arrives, and by then the record does not exist
- The From header, once you send on behalf of anyone else — their domain, your SPF and DKIM, and a DMARC policy that decides whether any of it arrives
- Deliverability drift, which is invisible. Nothing errors. Open rates fall, Gmail starts filing you under Promotions, then under Spam, and you find out from a friend who mentions they stopped seeing your emails
The import was 18,000 addresses from a conference list somebody handed you in a spreadsheet, and it went out at nine in the evening because that is when it finished rendering. By midnight SES has recorded a 7% bounce rate and 40 complaints, both well past the thresholds in the AWS docs. The automated review email arrives before you are awake, and the sending pause takes the whole account with it — which you discover at 07:40 when a customer says they cannot get a password reset link, because those go through SES too, from the same account, because of course they do. The newsletter is recoverable; you can apologise for it. The 18,000 people who marked you as spam are not, because their mailbox providers have now learned something about your domain, and unlearning it takes months of good behaviour you no longer have the sending volume to demonstrate.
Is that you?
the verdict is a default, not a law
- The list is you and nine colleagues on a domain you control, and "unsubscribe" means telling you in person
- It sends transactional mail only — one message, one recipient, triggered by that recipient's own action
- You are building the editor and the analytics, and handing the actual send to a provider's campaign API rather than a loop of your own
- Anyone on the list did not personally and recently ask to be on it
- The send loop is yours and it has no idempotency key per recipient per campaign
- The AWS account you would send from is the same one running anything you care about
- You cannot answer, for any given address, when they subscribed and from where
- You are sending on behalf of clients, under their domain
If you build it anyway
the checklist, then the prompt that enforces it
- Use a dedicated AWS account for sending, with nothing else in it. This one guardrail turns a sending pause from an outage into an inconvenience.
- Subscribe to the SES bounce and complaint SNS topics before the first campaign, not after. Hard bounces suppress permanently, complaints suppress permanently, and both are automatic or they do not happen.
- Every recipient of every campaign gets a row, written before the send and marked after it. A restarted job reads that table and skips anyone already sent to.
- One-click unsubscribe, no login, honoured immediately — and add the List-Unsubscribe and List-Unsubscribe-Post headers, which Gmail and Yahoo now expect from bulk senders.
- Double opt-in, and store the confirmation: timestamp, IP, source form, and the exact wording they agreed to. That record is the only defence you will have.
- Rate-limit and CAPTCHA the signup form, and never send a confirmation email to an address that failed either. Your form is a free email-sending API to anyone who finds it.
- Send to yourself, then to ten colleagues, then to a hundred, before anything larger. A warm-up schedule is not superstition, it is how mailbox providers decide what you are.
- Put the physical postal address in the footer of every campaign and a genuine reply-to on every From. Both are requirements, not decoration.
I am building a newsletter sender on top of Amazon SES. Treat my domain's
sending reputation and the risk of AWS suspending the account as the primary
constraints, above every feature. Push back if I ask for the editor first.
1. Before anything is built, tell me to create a separate AWS account used
only for sending. Refuse to wire this into an account running anything
else I care about.
2. First code: the suppression list. Subscribe to the SES bounce and complaint
SNS topics, persist every event, and make hard bounces and complaints
permanent suppressions that no import can override.
3. Then unsubscribe. One click, no login, honoured before the next send —
including the campaign already queued. Add List-Unsubscribe and
List-Unsubscribe-Post headers. Test it before any campaign exists.
4. Then the send ledger. One row per recipient per campaign, written before
the message goes out, marked after. Show me the test that kills the worker
mid-send and proves nobody is mailed twice.
5. Then consent. Double opt-in only, storing timestamp, IP, source form and
the exact wording agreed to. An import with no consent record is rejected
by the importer, not flagged.
6. Rate-limit and CAPTCHA the signup form before it is public, and never send
a confirmation to an address that failed either. Assume a bot finds it.
7. Sending starts throttled: a hard daily cap I set explicitly, and a ramp
that cannot increase without me changing a number.
8. Every campaign footer carries a physical postal address and a working
reply-to. Not a template variable I am allowed to leave blank.
9. Add a pre-send check that refuses to run above 4% bounce rate or 0.08%
complaint rate, and tell me the AWS thresholds those sit under.
10. Out of scope on purpose: sending from anyone else's domain, buying or
scraping addresses, and "re-engagement" campaigns to people who went
quiet. If I ask, say no and tell me to pay the $9 instead.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 for almost anyone. Nine dollars a month buys a team whose entire job is watching bounce rates you will not watch, an unsubscribe flow that is already compliant, and a suppression list that survives your bad CSV. The free tier covers 2,500 subscribers, which is more than most newsletters ever reach. If what you actually wanted was to own the data, self-host Listmonk and point it at SES — you keep the database and inherit an unsubscribe flow, a bounce handler and a rate limiter that other people have already debugged.
$9/mo is cheaper than your weekend.
Subscribers, consent records and suppressions export as CSV — export all three, not just the first, because a list without its suppression history is a list that will re-mail everyone who ever complained. The part that does not migrate is the reputation: DKIM keys, a warmed domain and whatever mailbox providers have concluded about you. If you are moving to a hosted provider, keep the same sending domain, authenticate it there before the first send, and go back to a warm-up ramp for a fortnight rather than resuming at your old volume.
Mature self-hosted newsletter manager with bounce processing, opt-in flows and an SES backend already wired up.
Open-source newsletter tool built around double opt-in and GDPR-shaped consent handling.
Questions
EmailOctopus itself is a thin layer over SES. Why can't I be?
You can be, architecturally. What you cannot be cheaply is the operations team behind it — the people who notice a complaint rate creeping up on a Tuesday, maintain the suppression list across every customer, and have a relationship with mailbox providers when something goes wrong. The code is the small half. The nine dollars buys the other half.
It's a hundred subscribers who all know me. Is this really ABSOLUTELY NOT?
At a hundred friendly subscribers the consequences are small, and the SHIP IT list above covers roughly that case. The verdict is calibrated for what this becomes: the list grows, someone imports a spreadsheet, and the thing that started as a hobby is now the channel your customers hear from you on. The failure mode does not scale gently — it arrives all at once, as a suspended account.
What is genuinely safe to build here?
The composer, the subscriber database, the segmentation and the analytics. All of that is yours and none of it can burn a domain. Hand the actual transmission to a provider's campaign API, which owns the throttling, the suppression list, the unsubscribe header and the reputation. You keep the interesting half and the irreversible half stays somebody else's problem.
Does CAN-SPAM apply to a free newsletter?
Yes. It covers commercial email regardless of whether you charge, and its requirements are concrete: no deceptive headers or subject lines, a clear opt-out, opt-outs honoured within ten business days, and a valid physical postal address in the message. GDPR adds the other half in Europe — you need a demonstrable record of consent for each address, which is a database column you have to design before you need it.
- CAN-SPAM Act compliance guide for business (FTC)
- GDPR Art. 7 — conditions for consent
- Amazon SES sending review process FAQs (bounce and complaint thresholds, account pausing)
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-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice