Should I vibe code
Hosted newsletters, campaigns, automations, transactional mail, and analytics
The code you wanted to write is on sale for $149. The part that burns your domain is not the code.
?
Their verdict, the Pay as you go 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
Mailcoach is an unusual entry, because the thing you are proposing to write is already on sale as source. A hundred and forty-nine dollars, once, gets you Spatie's actual campaigns, automations, segmentation and transactional code running on your own server against your own SES key — the same architecture you were going to build, minus the six months. That framing is the whole review, because the reason not to build a newsletter platform was never the platform. It is that sending forty thousand emails is a permanent act performed on the reputation of a domain that also delivers your password resets, that CAN-SPAM is priced per message, and that Article 7 puts the burden of proving consent on you rather than on the person complaining. Buying the licence does not remove any of that — self-hosted Mailcoach still leaves suppression, bounce processing and deliverability entirely yours. It just means the part you were excited about is a solved problem you can own outright, and the part that will get you was never code in the first place.
What actually breaks
not "if". the specific failures.
- The unsubscribe endpoint, which must work without a login, keep working for at least ten business days after a send, and which starts returning 500s in silence the first time you rotate a signing key
- Suppression, whenever it is evaluated as the list is assembled rather than per address at the moment each message is handed to the provider
- Bounce and complaint feedback, which arrives as SNS notifications to a webhook you will wire up last and read never — and which is exactly how Amazon decides whether you keep sending
- The SES account itself: cross the bounce or complaint threshold and it goes under review, and it is the same account your application uses for receipts and password resets
- The public signup form, which without double opt-in lets one script subscribe ten thousand strangers and makes your confirmation mail the spam
- Resumption after a crash. A worker restarted mid-campaign with no per-recipient idempotency key re-sends to everyone it already delivered to
- The template, which renders beautifully in your browser and collapses in Outlook, discovered by the entire list simultaneously
- The physical postal address and the List-Unsubscribe header — both statutory, both trivially absent from a template you wrote yourself
The campaign goes out at nine and the worker dies somewhere around nine thousand of fourteen thousand recipients. A rolling deploy, an OOM kill, it does not matter which. The retry does what you told it to and restarts the job from the beginning, because sends were recorded in a batch at the end rather than per recipient before delivery. Five thousand people get one copy, nine thousand get two, and a couple of hundred of them press the spam button on the second within the hour. SES puts the account under review that afternoon. It is also the account your application sends password resets and order receipts from, because that was obviously the sensible thing to do when you set it up eighteen months ago, and for the next four days the loudest problem in the company is not the newsletter.
Is that you?
the verdict is a default, not a law
- It goes to you and a handful of colleagues who asked, from a domain that carries nothing else
- You bought the self-hosted licence and are configuring it rather than writing it
- Every address on the list confirmed itself by clicking a link in a message you can still produce
- Marketing leaves from its own subdomain with its own DKIM key, separate from the one your receipts use
- The list came from an import and you cannot answer, per address, when and how that person consented
- Marketing and transactional mail share a sending identity
- Suppression is not checked per address at send time on every path, including test sends and resends
- You are treating SES, Postmark or Mailgun as a dumb SMTP relay — their suppression lists and feedback loops are most of what you are paying for
If you build it anyway
the checklist, then the prompt that enforces it
- Before anything else, price the alternative honestly: the licence is a one-off 149 USD and the hosted plan starts under ten. Compare that against the weeks you are about to spend building a worse version of the same thing.
- Build the unsubscribe path first — signed, non-guessable, works with no login, idempotent, and survives a key rotation. Write the test that a link generated before the rotation still unsubscribes.
- Enforce suppression inside the sender, per address, immediately before handing each message to the provider. Not in the campaign builder, not once when the segment was computed.
- Write an idempotency key per recipient before delivery, not after. Campaign workers get restarted, and a resend to nine thousand people is one crash away.
- Wire the provider's bounce and complaint feedback into automatic suppression on day one, and alert on the rate rather than checking a dashboard you will stop opening.
- Separate subdomains and DKIM keys for marketing and transactional mail, so a burnt reputation does not take your password resets with it.
- Double opt-in on every signup path, with consent stored as data — timestamp, source URL, IP, and the exact wording shown — rather than as membership of a list.
- Stage every send: yourself, then ten, then a hundred, with a manual gate between stages and a hard cap that the process enforces by refusing rather than warning.
I am building a newsletter platform: campaigns, lists, segmentation, automations and transactional mail, sending through my own SES or Mailgun account. Refuse the interesting parts until the boring ones exist. 1. First, tell me that Mailcoach sells this exact system as a one-off licence for 149 USD, and ask whether I have a reason to write it instead. If my reason is "it looks fun", say so plainly and continue anyway. 2. Build the unsubscribe endpoint before the send path. Signed token, no login, idempotent, recorded immediately, and still valid after I rotate the signing key. Write that rotation test first. 3. Then suppression, enforced inside the sender, per address, immediately before each message goes to the provider. Every path goes through it — test sends, resends, automations, transactional. 4. Then idempotency: a key per recipient per campaign, written before delivery, with a unique constraint in the database. Assume the worker will be killed mid-campaign, because it will be. 5. Then feedback: subscribe to the provider's bounce and complaint notifications, suppress automatically, and alert me on the rate. Do not build a dashboard I have to remember to open. 6. Consent is data, not membership. Timestamp, source URL, IP and the exact wording shown at signup. Double opt-in on every path. If I ask for an import that marks addresses as subscribed, refuse and explain what a spam trap does to a sending domain. 7. Enforce SPF, DKIM and DMARC on a marketing subdomain that is not the one my transactional mail uses, and bake the postal address and List-Unsubscribe header into the base template so no campaign can exist without them. 8. Stage sends — me, ten, a hundred, the rest — with a manual gate between stages and a hard cap the sender enforces by refusing. 9. Finish by writing "Obligations I have taken on" in the README: proving consent, honouring unsubscribes, the postal address, bounce handling, deliverability. Then tell me again about the 149 USD licence.
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 there are two right answers rather than one. Under ten dollars a month with two thousand emails included buys you somebody else's deliverability team. A hundred and forty-nine dollars once buys you the same product as source on your own server, which is the answer if the reason you wanted to build it was control rather than price. What neither of them buys, and what no purchase can buy, is the sending reputation of your primary domain — that is the thing you are actually risking, and it is not for sale at any figure.
$9.99/mo is cheaper than your weekend.
Three things are the asset and none of them is the software: the address list, the per-address consent record, and the suppression list. Keep all three exportable as CSV from the first commit. If you have to move onto Mailcoach or a real ESP mid-incident, the consent record is what lets you import without warming a reputation from zero, and the suppression list is what stops you re-mailing everyone who already complained — which is the specific mistake that turns a bad week into a burnt domain.
High-performance self-hosted newsletter and mailing-list manager in a single binary. Solves the software; consent and deliverability stay yours.
Open-source marketing automation with campaigns, segments and drip flows. Heavy to run, but it is the real self-hosted analogue.
Self-hosted newsletter tool with an API, considerably lighter to operate than Mautic.
Questions
If I can self-host it for $149, why is the verdict ABSOLUTELY NOT?
Because the verdict is about building your own, not about where the software runs. Buying the licence and deploying it is configuration, and it is a completely reasonable thing to do — it appears in the SHIP IT list on this page. Writing your own campaign engine, suppression logic and unsubscribe endpoint is the thing being rated, and the existence of a 149 dollar alternative makes that choice harder to defend, not easier.
Isn't sending through SES already "using a provider", like the guardrails say?
Only partly, and the distinction is the entire argument. A full ESP owns suppression, complaint feedback, the unsubscribe endpoint and its own reputation with the inbox providers. SES sells you delivery and holds you responsible for everything else — it will suspend your account over a bounce rate it expects you to have prevented. Treating SES as a relay is how people end up owning deliverability without noticing they took the job.
It is three hundred people on a list I collected myself. Really ABSOLUTELY NOT?
At that size most of this is proportionate rather than absent. Three hundred people who each typed their own address and confirmed it, sent from a domain carrying nothing else, is close to the SHIP IT case at the top of the page. The verdict describes the shape the product actually sells: automations, transactional mail and campaigns going out at volume from infrastructure you also depend on for everything else.
What is the single most dangerous thing to let an agent build here?
The campaign worker's retry logic. It looks like plumbing, an agent will write it without comment, and its failure mode is the only one on this page that cannot be apologised for. Recording sends in a batch at the end of the run rather than per recipient before delivery is one crash away from mailing thousands of people twice, which is the fastest route from a normal Tuesday to an account review.
- 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.
Small list, same law. The compliance floor does not scale down with your subscriber count.
Sending bulk email is 5% code and 95% not getting your domain blacklisted forever.
SendFox makes you pay to turn off double opt-in. Your version will ship with it off, for free.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice