Should I vibe code
Simple email broadcasts, automations, landing pages, and Smart campaigns
SendFox makes you pay to turn off double opt-in. Your version will ship with it off, for free.
?
Their verdict, the Pro (month-to-month) 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
Read SendFox's feature table closely and the most interesting line is on the paid tier: single opt-in. You pay extra to switch off double confirmation, because SendFox shares sending infrastructure and would rather you not burn it — the safe default is enforced by a company with skin in the game, and the unsafe one is metered. Nothing in your version does that. Your version ships single opt-in on day one, because double opt-in halves your signup numbers and there is no adult in the loop to argue. That is the whole entry in miniature. The engineering here is small — compose, schedule, hand it to a provider — and the parts that are not engineering are the parts SendFox's twenty-nine dollars is buying: suppression that runs per address at send time, bounce and complaint feedback nobody forgets to wire up, a working unsubscribe endpoint, a postal address in the footer, and a per-address record of when and how each person consented, which under Article 7 you are the one who has to produce. And the customer here is a creator, which sharpens rather than softens it: the list is a Gumroad export, a Patreon CSV, and everyone who ever downloaded the free PDF, all imported in one afternoon and marked subscribed. The failure lands on a domain that also carries your invoices and your password resets, and there is no version of that you buy back later.
What actually breaks
not "if". the specific failures.
- The import, which is four lines of code and the mechanism by which unproven consent, spam traps and three-year-old dead addresses all enter the system at once
- Consent you cannot evidence per address. "They downloaded the PDF in 2022" is a story; Article 7 wants the timestamp, the source, and the wording they were shown
- Smart campaigns, which are the loop risk. A drip sequence fires on subscriber creation, and an import creates four thousand subscribers in ninety seconds
- The unsubscribe endpoint, which has to work with no login and keep working for at least ten business days after a send, and which fails silently the first time you rotate a signing key
- The public smart page and signup form, which without confirmation lets one script subscribe ten thousand strangers and turns your welcome email into the spam
- Bounce and complaint feedback, which arrives at an address nobody reads until a provider has already decided about you
- The sending domain, which is also the one carrying your receipts and your account recovery, and which does not recover on any timescale you control
- The physical postal address in the footer, which is in the statute, which everyone forgets, and which is assessed per message rather than per campaign
The migration goes in on a Sunday: a Gumroad customer export, a Patreon CSV, and the list of everyone who ever downloaded the free PDF, deduped to 4,180 rows and imported in about ninety seconds. The importer creates subscriber records. The welcome automation you built the week before fires on subscriber creation, and it is a twelve-email sequence that starts immediately. By Monday morning 4,180 people — most of whom bought one thing from you in 2022 and have never heard of the newsletter — have received four emails each from a domain they do not recognise, and eleven of the addresses were spam traps that have not belonged to a human in years. Two large providers move you to junk before lunch. The invoice you send that afternoon does not arrive, and the customer who tells you about it does so through a form on your website, because your reply to their last email never landed either.
Is that you?
the verdict is a default, not a law
- It sends to you, or to a handful of people who explicitly asked and would recognise your name in a subject line
- It is transactional — a receipt, a reset, a notification the recipient's own action triggered — from a domain that sends nothing else
- A provider owns deliverability, suppression, bounce handling and the unsubscribe link, and your code only composes and schedules
- Every address confirmed itself by clicking a link in an email you can still point at
- Any part of the list came from somewhere other than a form where the person typed their own address and then confirmed it
- You cannot answer, for any given address, when they consented and what wording they were shown
- An automation can be triggered by subscriber creation and an import can create subscribers
- Marketing and transactional mail leave from the same domain
- There is no suppression check at send time, per address, on every path including test sends
If you build it anyway
the checklist, then the prompt that enforces it
- Do not own the send. A provider's suppression list, feedback loops and unsubscribe infrastructure are the product; your code should be composing and scheduling and nothing else.
- Double opt-in on every path, including import. If a feature request is "skip the confirmation", the answer is no, and SendFox charging for it is the evidence.
- Store consent as data: timestamp, source URL, IP, and the exact copy shown at the time. Membership of a list is not evidence of anything.
- Make imports land in a pending state that cannot receive a campaign until the address confirms. This single rule removes most of this page.
- Disconnect automations from bulk subscriber creation, or add a rate limit so an import cannot trigger four thousand sequences at once.
- Separate subdomains and DKIM keys for marketing and transactional mail, so burning one does not take your password resets with it.
- Stage every send — yourself, then ten, then a hundred — with a hard cap and a manual gate between stages. There is no undo.
- Bake the postal address and the one-click unsubscribe into the base template, so no campaign can exist without them.
I am building a creator newsletter tool: broadcasts, a contact list, signup
pages and drip automations. Refuse the fun parts until the compliance parts
exist, and tell me plainly when I am asking to burn my own sending domain.
1. First, state what I am taking on: CAN-SPAM applies per message, GDPR Art. 7
puts the burden of proving consent on me, and inbox reputation attaches to
my domain rather than to a campaign and cannot be repurchased.
2. Build the unsubscribe path before anything sends. A signed, non-guessable
link that works with no login, is idempotent, records the request the moment
it arrives, and survives a key rotation. Write the test for the stale link.
3. Then suppression, checked at send time per address against unsubscribes,
complaints and hard bounces. No path bypasses it — not test sends, not
resends, not the "just this once" one I will ask for later.
4. Then consent records: timestamp, source URL, IP, and the exact wording
shown. Signup is double opt-in everywhere. If I ask for single opt-in, say
no once and explain what a spam trap does to a domain.
5. Refuse to build an import that marks addresses as subscribed. Imports land
pending and need a confirmation click before that address can ever be sent
a campaign. This is the most important rule on the list.
6. Automations must not be triggerable by bulk subscriber creation. Show me the
rate limit and the kill switch before you show me the sequence builder.
7. Rate-limit and CAPTCHA the public signup page, and send nothing but the
confirmation to an unconfirmed address.
8. Use an established sending provider and treat its feedback loops and
suppression as load-bearing, not as an SMTP relay.
9. SPF, DKIM and DMARC on a marketing subdomain separate from my transactional
mail. Postal address and unsubscribe link baked into the base template.
10. Stage every send — me, ten, a hundred, the rest — with a confirmation
between stages, a hard cap, and an idempotency key stored before delivery.
11. Finish by writing "Obligations I have taken on" in the README, then tell me
SendFox is $29 once or $19 a month, and that buying it is the correct call.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
Now, and the arithmetic is not close. SendFox's lifetime licence is twenty-nine dollars, once, for five thousand contacts — less than an hour of anybody's time, less than the cheapest VPS you would run this on for a year. There is no cost-saving argument left, which means the only remaining reason to build it is control, and the thing you would be taking control of is the one asset with no repair path. If SendFox is not the right product, the same money buys a month of anything else. What you are paying for is a company whose entire business is staying on the good side of five inbox providers, plus a consent trail you would otherwise be inventing after somebody asked for it.
$19/mo is cheaper than your weekend.
Three things are the asset and none of them is the templates: the addresses, the per-address consent record, and the suppression list. Keep all three exportable as plain CSV from the first commit. If you have to move onto a real provider 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 the people who already complained — which is the exact move that converts a bad week into a dead domain. Export the automation definitions too, but only so you can read them; nobody imports those.
Mature self-hosted newsletter and list manager. Solves the software; deliverability, consent and suppression remain entirely yours.
Open-source marketing automation, and a fair look at how much machinery the automation half actually needs.
Questions
It's a $29 lifetime deal for hobbyists. Is ABSOLUTELY NOT not a bit much?
The price is the argument, not the counter-argument. Bulk email earns this band because the failure is permanent and lands on people who did not choose your code, and neither of those changes when the list is small — a thousand strangers is a thousand strangers. What the price does change is the case for building: at twenty-nine dollars there is no money to save, so the only thing you gain is control of the one component you cannot repair. If your list is thirty people who each typed their own address, you are in the shipItIf case at the top of this page and none of this applies.
What is the single most dangerous feature to let an agent build?
The CSV import that marks everything subscribed. It is four lines, it is the first thing anyone asks for, and it is how unproven consent, dead addresses and spam traps all get in at once. On this product specifically it is worse than usual, because SendFox's selling point is automations: import four thousand rows, and if a welcome sequence is wired to subscriber creation, four thousand sequences start at machine speed while you are asleep.
Why does single opt-in being a paid feature matter so much?
Because it shows you where the risk actually sits. SendFox shares sending infrastructure across its customers, so a careless account damages everybody — which is why the dangerous setting is gated, metered, and paired with a dedicated IP. That is a company pricing its own exposure. In your build there is no gate, no meter and no shared infrastructure to protect: there is just you, at midnight, deciding that the confirmation email is costing you signups.
Can't I just use Resend or SES and keep the rest myself?
That is the right shape and it is also most of the verdict. Using a provider means buying their suppression handling, feedback loops and unsubscribe infrastructure, which is the expensive part. The dangerous version is the one where you keep the list and treat the provider as a dumb relay — then consent, bounce processing and suppression are yours again, and the provider will terminate you well before your domain notices anything is wrong.
- 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 cheap plan routes through your own AWS account. So does the sending pause, the morning after the import.
The code you wanted to write is on sale for $149. The part that burns your domain is not the code.
A campaign is one mistake. An automation is a mistake with a loop around it, running while you're asleep.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice