Should I vibe code
Newsletter publishing, growth, monetization, and email platform
Nobody has ever regretted paying someone else to own their sender reputation.
?
Their verdict, the Scale 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
Publishing is the easy part and you should absolutely own it. The sending is the part where one misconfigured DKIM record means your newsletter silently stops arriving for months before you notice.
What actually breaks
not "if". the specific failures.
- DKIM signing that passes your own test and fails DMARC alignment, so mail is accepted and filed in spam
- Paid subscriptions, which are recurring billing plus entitlement plus refunds, not a Stripe button
- The archive, which paying subscribers believe will resolve at that URL in 2029
- A suppression list checked when the list was built rather than at send time, so someone who unsubscribed gets the next issue
- Sending volume too low and too spiky to hold a reputation on your own IP
Your open rate did not drop. Your delivery did. Six weeks ago you moved to a new sending domain and the DKIM selector on the new one signs correctly but does not align with the From header, so DMARC fails and Gmail quietly files you under Spam. Opens still look plausible because your most loyal readers dig you out. You find out when a subscriber emails to ask, kindly, whether you stopped writing. You did not. You sent eleven issues into a folder nobody opens.
Is that you?
the verdict is a default, not a law
- The sending goes through a real provider's API and you only built the editor and the public archive
- It is your own site's archive page and someone else owns the mail
- It goes to colleagues who can walk to your desk when it breaks
- You are taking recurring money for it
- You are running your own SMTP server or a self-managed MTA
- Anyone on the list did not explicitly ask to be there
- A total delivery failure would be invisible to you for more than a day
If you build it anyway
the checklist, then the prompt that enforces it
- Never run your own MTA. Use SES, Postmark or Resend and let a company whose job is reputation own your reputation.
- Build the unsubscribe path before the send path. One click, honored inside the same send, no login, no confirmation step.
- Check the suppression list per recipient at send time, not when the batch is assembled.
- Record consent for every subscriber: timestamp, source, and IP. You will be asked to prove it.
- Seed every send to a Gmail, an Outlook and a Yahoo address you own, and alert yourself when one lands in spam.
- Paid subscriptions are out of scope unless you are using Stripe Billing and have already written the refund policy.
Before you write any code for a newsletter platform, apply these and push back if I ask you to break them. 1. Do not build or configure an SMTP server. Send through the API of an established provider — SES, Postmark, Resend. If I ask you to self-host an MTA, refuse and explain that IP reputation takes months to build and one bad send to destroy. 2. Implement unsubscribe before you implement send. One click from the email, no login, no 'are you sure', honored immediately. Add the List-Unsubscribe and List-Unsubscribe-Post headers. 3. Check suppression per recipient at the moment of sending, not when the batch is built. Show me the code path where a person who unsubscribed during a send is skipped. 4. Every subscriber record stores consent: the timestamp, the source, and the IP that submitted it. No import path may create a subscriber without them. 5. Set up SPF, DKIM and DMARC, then write a check that verifies DKIM *alignment* with the From domain, not just that a signature exists. Fail loudly on startup if alignment is broken. 6. Add a seed list — one Gmail, one Outlook, one Yahoo address I control — that receives every send, plus a check that reports which folder it landed in. 7. Rate limit sends and ramp volume gradually. A cold domain sending ten thousand messages on day one is a blocklist entry. 8. Treat paid subscriptions as out of scope. If I insist, use Stripe Billing, never store a card, and make me write the refund and cancellation policy before you write the checkout. 9. Tell me plainly in the README that deliverability failure is silent, that I will not notice it for weeks, and that $49 a month buys someone whose job is noticing.
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
Almost certainly. $49 a month is less than one deliverability incident costs you in readers who never see the unsubscribe link because they never see the email. Own the writing and the archive; rent the sending.
Export subscribers with their consent records — timestamp, source, IP — as CSV on day one, and confirm the import actually completes into a real provider before your list matters. A list you cannot move with its consent history attached is a list you cannot legally use anywhere else.
Open-source publishing/newsletter platform with memberships and email support.
Questions
I'm only sending to 300 people. Does any of this apply?
The law does, in full — CAN-SPAM and GDPR do not have a hobbyist threshold. The deliverability problem is actually worse at low volume, because you never send enough for a provider to build a stable reputation for you, and a single spam complaint is a much larger fraction of your traffic.
What if I use SES and just write the editor and archive myself?
That is the SHIP IT version of this project and it is a genuinely good one. Amazon owns the reputation and the hard delivery problem; you own the writing experience and your archive URLs. The remaining work is unsubscribe handling, suppression and consent records — real, but bounded.
- 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.
Your reputation as a sender is an asset you can destroy in one bad loop and never rebuild.
Sending bulk email is 5% code and 95% not getting your domain blacklisted forever.
Paid memberships mean people are owed access. Access has to survive your enthusiasm.
last reviewed 2026-08-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice