Should I vibe code
Email marketing, behavioral tracking, segmentation, and automation
A campaign is one mistake. An automation is a mistake with a loop around it, running while you're asleep.
?
Their verdict, the Marketing Platform 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
Bento is not a newsletter tool with tracking bolted on; it is an event pipeline with a send button on the end. Something happens in your app, a rule fires, mail goes out — and that inversion is what makes the homemade version dangerous in a way a plain campaign sender is not. A campaign you press send on once is a mistake with a known size. An automation is a mistake that keeps running, at machine speed, while you sleep, and the classic failure is a loop: the email's own tracking event satisfies the condition that triggered it, and by morning one subscriber has four hundred copies and your domain has a reputation. Underneath that sits the second problem, which is that Bento sends your receipts and password resets from the same account as your campaigns, and a homemade suppression list that does not distinguish the two will either mail people who opted out or stop sending account recovery to people who merely unsubscribed from the newsletter. Both are bad. One of them is a regulator's business.
What actually breaks
not "if". the specific failures.
- The automation loop: an email's open or click event satisfies the condition that triggered the email, and the same person receives it every few minutes until someone wakes up
- Suppression scope, where unsubscribing from a newsletter also stops the password-reset mail, or — the other way round — an opt-out on the marketing side never reaches the campaign sender at all
- The public form endpoint, which is a list-bombing weapon the moment it accepts an address with no confirmation step, and which puts your domain in the middle of someone else's harassment campaign
- Double-sending on retry, because the queue redelivers and the send handler was not idempotent per subscriber per automation step
- Your sending reputation, spent in one night, and shared with every transactional message your product depends on
- The behavioural profile itself, which is a per-named-person record of everything they did in your app, held for as long as you never got round to deleting it
- Bounce and complaint handling, where continuing to mail a hard bounce is precisely how a domain goes from mediocre to blocked
- A deletion request, which has to reach the subscriber row, the event stream, the segment memberships, the automation state, the send log and the CSV somebody exported in March
The rule is reasonable: when a user has viewed the pricing page and not upgraded, wait a day and send the nudge. What you did not notice is that the nudge's own click-tracking redirect lands on the pricing page, and the tracker fires the same event it is keyed on. The condition is satisfied again. The delay is a day in the editor and a minute in the queue because someone set it in the wrong unit during testing. By the time a subscriber replies — in capitals, at 06:40 — one person has received four hundred and eleven copies, several hundred others have a dozen each, and Gmail has drawn its own conclusions. There is no unsend. The complaint rate crosses the threshold where your domain stops being delivered at all, and the first thing you discover is that this also covers your password reset emails, so the customers who now want to close their accounts cannot log in to do it.
Is that you?
the verdict is a default, not a law
- It sends nothing. A behavioural event store with segmentation and no delivery path is a genuinely useful thing to build and carries none of this
- The only mail is transactional, one message per user action, through a reputable provider's API, with no campaign feature anywhere near it
- The list is fewer than a hundred people who all know you personally and all replied to be added
- Any rule can send mail without a human pressing a button
- Marketing and transactional messages share one suppression list, one sending domain and one reputation
- The signup form accepts an address without a confirmation click
- You cannot produce, per subscriber, the date and source of their consent
- There is no per-person-per-day send cap enforced at the queue
If you build it anyway
the checklist, then the prompt that enforces it
- Cap sends per recipient per day at the queue, not in the rule editor, and make the cap something a rule cannot raise. This single check converts the automation-loop disaster into a log line.
- Never let a message's own tracking events feed the segment that triggered it. Tag every event with its source and exclude email-originated events from automation conditions by default.
- Separate marketing and transactional completely — different subdomains, different providers, different suppression tables, different credentials. A marketing unsubscribe must never suppress account-recovery mail, and a transactional path must never be reachable from a campaign.
- Require confirmed opt-in on every public form. An endpoint that adds an address to a mailing list on one unconfirmed request is a tool for mailing someone they dislike, using your domain.
- Make every send idempotent on (subscriber, automation, step), enforced by a unique constraint. Queues redeliver; that is their job.
- Store consent as a record — timestamp, source, IP, the wording shown — because 'where did you get my address' is a question with a legally interesting answer.
- Process bounces and complaints automatically and permanently. A hard bounce is never retried, and a complaint suppresses immediately, everywhere.
- Build a kill switch that halts every automation and drains the queue, and test it before you enable the first rule. You will need it while you are half awake.
- Set retention on the behavioural event stream at the start. 'Everything every user ever did, forever' is not a design, it is what happens when nobody chose.
I am building an event-triggered email platform: behavioural tracking, segments,
automations and sends. Treat the send path as the hazard and the dashboard as
decoration. Refuse the order if I ask for it backwards.
1. Before any rule engine, build the rails: a global kill switch that pauses every
automation and drains the queue, a per-recipient-per-day send cap enforced in the
queue, and a dry-run mode that renders and logs without delivering.
2. Make every send idempotent on (subscriber, automation, step) with a database unique
constraint. Assume the queue will redeliver, because it will.
3. Tag events with their source, and exclude email-originated events — opens, clicks,
tracking redirects — from automation triggers by default. Refuse to build a rule
whose action can satisfy its own condition, and explain loop detection to me first.
4. Keep marketing and transactional physically separate: separate sending subdomains,
provider credentials and suppression tables. A marketing unsubscribe must never
suppress a password reset; a campaign must never reach the transactional path.
5. Public subscribe endpoints require confirmed opt-in, per-IP rate limiting and a bot
check. Tell me an unconfirmed subscribe endpoint is a list-bombing tool with my
domain on it.
6. Store consent per subscriber: timestamp, source, IP, and the exact wording shown.
This is a record, not a boolean.
7. Unsubscribe is a one-click link with no login, honoured everywhere within seconds,
plus List-Unsubscribe headers — built and tested before the first template exists.
8. Handle provider bounce and complaint webhooks: hard bounce suppresses permanently,
complaint suppresses immediately, neither is ever retried.
9. Set up SPF, DKIM and DMARC and a warm-up schedule before any volume, and state the
daily ceiling you are ramping to.
10. Set a retention period on the event stream, and implement deletion across
subscriber, events, segments, automation state and send logs as one list in code.
11. Then say out loud: for $29/month Bento does all of this and employs people who
watch the reputation dashboards. Ask whether I still want to own it.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 this is not close. $29 a month for 5,000 contacts buys deliverability engineering, suppression handling, bounce and complaint processing, and a company whose entire business depends on your mail arriving — none of which you will build in month one and all of which you need in week one. Build the interesting half if you want: an event store and a segmentation engine over your own product data is genuinely useful and completely safe. Hand the actual sending to someone who does this for a living.
$29/mo is cheaper than your weekend.
The subscriber list and the consent records are the portable part — export both as CSV on a schedule, with the consent timestamp, source and wording attached, because that is the artefact any other provider will need and the one you cannot reconstruct later. The event stream is worth keeping in your own warehouse regardless. The part with no exit is your sending domain: reputation does not migrate, cannot be repaired quickly, and is shared with every transactional message your product sends. If you have already burned it, the honest recovery is a new subdomain, a slow warm-up on a real provider, and several weeks of patience.
Self-hosted newsletter and mailing-list manager with subscriber management and campaign sending.
Open-source marketing automation with campaign builders and behavioural tracking already modelled.
Questions
Every bulk-email entry on this site is ABSOLUTELY NOT. What is specific to Bento?
The trigger. Mailchimp's failure is a campaign you sent to the wrong list — one event, one apology. Bento's shape is an automation that fires from events in your product, which means the failure mode has a loop in it and runs unattended. The other Bento-specific hazard is that it carries your transactional mail too, so a homemade suppression list that gets its scope wrong either mails opt-outs or blocks password resets.
Can I build the tracking and segmentation half safely?
Yes, and it is the interesting half. An event store keyed to your own users, with a segment builder over it, has no deliverability story, no reputation to burn and no unsend problem. Keep it strictly read-only with respect to email — it produces lists, it does not press send — and hand those lists to a provider's API. That single boundary is most of the difference between this entry and a DEMO ONLY.
What actually stops the loop?
A per-recipient-per-day cap enforced in the queue, below the rule engine, that no automation can override. Loop detection in the trigger evaluator is worth having as well, but it is the kind of logic that is correct until someone adds a rule you did not anticipate. The cap is dumb, is checked on every single send, and turns the incident in this entry into three extra emails and a log line.
- 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.
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.
Transactional and marketing mail have different rules, and mixing them poisons both.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice