shouldivibecodeit

Should I vibe codeCampaign Monitor?

Compose branded campaigns, manage subscribers, and report delivery and clicks

Send is not deploy. There is no rollback for a template that renders wrong in Outlook — and Outlook is Word.

?

Their verdict, the Lite price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.

Can you build it?asked by canivibecodeit.com ↗KINDAweekend project · multi-day
?

Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.

Should you ship it?asked by usABSOLUTELY NOTthe thing you break isn’t code.

The honest answer

why the verdict is what it is

The rest of this category argues about deliverability and consent, and all of that applies here too. What makes Campaign Monitor its own case is who the From header belongs to. This is the product agencies and in-house brand teams run campaigns through on behalf of somebody else, which means the domain you are about to burn is a client's, the subscribers are theirs and not yours, and the relationship between you has a data processing agreement in it whether or not either of you has read one. Underneath that sits the thing Campaign Monitor is genuinely famous for — the email rendering matrix — and it deserves saying plainly: a template that breaks in Outlook cannot be fixed after the send. There is no rollback. The bad version is simply what forty thousand people received.

What actually breaks

not "if". the specific failures.

  • The render, in the one client you did not check — Outlook on Windows lays out mail with Word's engine, which does not do flexbox, grid, or background images without VML, and the failure is a wall of stacked full-width images
  • Dark mode, which inverts colours differently in Outlook.com, Apple Mail and Gmail, and turns a logo with a white matte into a black rectangle
  • The send itself, which is not a deploy: there is no rollback, no hotfix and no version you can quietly replace, only forty thousand copies of whatever you got right
  • Your client's sending domain, which you authenticated with SPF and DKIM, and which carries their order confirmations as well as your campaign
  • The processor relationship, because it is their subscriber list and their obligation — a breach on your box starts a 72-hour clock that lands on their legal team
  • The unsubscribe endpoint, which has to work without a login for at least ten business days after every send and which fails silently the first time a signing key rotates
  • Consent provenance for a list you inherited, exported from a system nobody at the agency has credentials for any more
  • Link tracking, which rewrites every URL in the campaign through your redirector — retire it and every link in every archived newsletter dies at once
and then, at 3am

The client's Black Friday campaign goes out at six on the Thursday to thirty-eight thousand people, and the first replies start about nine minutes later. The hero block uses a background image, which Outlook on Windows renders as nothing at all unless you wrapped it in VML, so a third of the list is looking at a white rectangle with a price on it and no context. That is annoying and survivable. What is not survivable is the second thing: the unsubscribe link in the footer points at a signed URL, the signing key rotated during a deploy on Tuesday, and every unsubscribe click since has returned a 500. By the time anyone connects those two facts, the complaint rate has crossed a threshold at two large providers, the reputation attaches to the client's domain rather than to your campaign, and their order confirmations are going to spam on the busiest retail weekend of the year. You cannot resend. You cannot recall. Everything you can do from here is an apology and a conversation with someone whose name is on the contract.

Is that you?

the verdict is a default, not a law

ship it if
  • The recipients are you and a handful of colleagues who explicitly asked
  • It is transactional mail on a domain that sends nothing else, triggered by the recipient's own action
  • An established provider owns delivery, suppression, bounce handling and the unsubscribe endpoint, and your code only composes and schedules
  • You did not write the HTML template — you used a maintained, tested framework and rendered it through a preview service before sending
don’t ship it if
  • The From address is on a domain you do not own
  • You are sending on behalf of a client, which makes you a processor under a contract you should read before the first send
  • The list arrived as a CSV and nobody can say, per address, when and how consent was given
  • You cannot preview the campaign in Outlook on Windows before it goes
  • 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

  1. Do not own the send. Use a provider whose business is deliverability, suppression, bounce handling and the unsubscribe endpoint, and keep your code to composition and scheduling.
  2. Do not hand-write email HTML. Use a maintained framework — MJML or a battle-tested table-based template — and render every campaign through a real preview service covering Outlook on Windows, Gmail's clipping limit and dark mode, before anything is scheduled.
  3. Never authenticate a client's domain against your own sender without a written agreement about who owns the reputation and what happens when it is damaged. That conversation is much cheaper before the send.
  4. Build the unsubscribe path first: a signed, non-guessable link that works without a login, survives key rotation, is idempotent, and records the request before rendering anything. Then write the test where a stale link still unsubscribes.
  5. Suppression is checked at send time, per address, against unsubscribes, complaints and hard bounces — including on test sends and resends, which is exactly where the bypass gets added.
  6. Store consent as data and not as list membership: timestamp, source URL, IP and the exact wording shown. If you are sending for a client, get that record from them in writing before the first campaign.
  7. Stage every send — yourself, then ten, then a hundred, then the rest — with a manual gate and a hard cap between stages, and an idempotency key written before delivery. The staging is not caution, it is the only place a render bug can still be caught.
  8. Separate subdomains and DKIM keys for marketing and transactional mail, so burning one does not take order confirmations with it.
the guardrail prompt
I am building campaign email that will be sent on behalf of a client, from their
domain, to their subscriber list. Refuse the fun parts until the irreversible
parts are handled, and be blunt about what I am taking on.

1. Start by telling me what changes because the domain is not mine: I am a
   processor, the consent records belong to the controller, a breach starts a
   72-hour clock on their obligation, and the reputation I can damage is theirs.
2. Build the unsubscribe path before anything else — signed, non-guessable,
   works with no login, idempotent, records the request before rendering, and
   survives a signing-key rotation. Write that test explicitly.
3. Then suppression, enforced at send time per address against unsubscribes,
   complaints and hard bounces. No path bypasses it: not previews, not tests.
4. Then consent records — timestamp, source URL, IP, exact wording shown. Refuse
   a CSV import that marks addresses subscribed; imports land pending.
5. Do not hand-write email HTML. Use MJML or equivalent. Assume Outlook on
   Windows renders with Word: no flexbox, no grid, background images need VML.
   Handle dark mode and stay under Gmail's clipping limit.
6. Add a blocking preview gate: nothing schedules until it has been rendered
   against Outlook on Windows, Gmail and Apple Mail, in light and dark.
7. Stage every send — me, ten, a hundred, the rest — with manual confirmation
   between stages, a hard cap, and an idempotency key stored before delivery.
   Say out loud that there is no rollback after stage one.
8. Use an established sending provider and treat its suppression and feedback
   loops as the product, not as an SMTP relay.
9. SPF, DKIM and DMARC on a marketing subdomain separate from transactional
   mail; postal address and one-click unsubscribe baked into the base template.
10. If I ask for click tracking, tell me it makes my redirector a permanent
    dependency of every archived newsletter.
11. Finish with a README section "Obligations I have taken on" — consent proof,
    unsubscribes, postal address, bounce handling, the processor relationship —
    then tell me to buy this instead.
paste this before you build — not after something breaks31 lines · 2154 chars

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

just pay for it

Before you write a line, and the subscription price is not really the comparison. What you are buying is a company whose full-time job is staying on the right side of five inbox providers, a rendering pipeline tested against Outlook versions you have never installed, and an unsubscribe endpoint that someone else is paged about. Set against that: CAN-SPAM is priced per message, and the sending reputation of a client's domain is not for sale back to you at any figure.

$12/mo is cheaper than your weekend.

your exit plan, if you already built it

Three things must be exportable from the first day and none of them is the template library: the address list, the per-address consent record, and the suppression list. If you are sending for a client, add a fourth — a written statement of who owns each of those, because the day the relationship ends, the argument is about whether the list leaves with them. Moving to a real provider mid-incident works only if the consent record travels with the addresses, and re-mailing people who already complained is the specific mistake that turns a bad week into a burnt domain.

prior art · someone already did this
Listmonk

Mature self-hosted newsletter and mailing-list manager. It solves the software; deliverability, consent and rendering remain entirely yours.

MJML

Markup language that compiles to email HTML which survives Outlook, and the single highest-value thing to adopt if you build any of this.

Questions

Everything on this list is ABSOLUTELY NOT. What is different here?

Two things the neighbours do not have. First, the From header belongs to somebody else: Campaign Monitor's centre of gravity is agencies and brand teams sending for clients, so the domain at risk is not yours and the subscribers are not yours either, which turns a technical failure into a contractual one. Second, the rendering. Campaign Monitor's reputation was built on email HTML craft, and rendering is the one category of bug that cannot be patched after deploy, because the deploy already landed in forty thousand inboxes.

How bad is Outlook, honestly?

Outlook on Windows lays out HTML mail using Microsoft Word's rendering engine. In practice that means no flexbox, no grid, unreliable padding on anything that is not a table cell, background images only via VML, and a habit of ignoring max-width. A layout that is perfect in every browser and in Gmail can arrive as a single column of stretched full-width images. It is not an edge case — it is a large share of most B2B lists, and it is the reason serious senders use a compiler rather than hand-written HTML.

I am the client and the developer. Does the processor argument still apply?

Not in the contractual sense, and that genuinely removes one layer. What stays is everything else: the same domain reputation, the same unsubscribe obligations, the same irreversible send. Being your own client means nobody will sue you over it, which is a real improvement to the worst day, but it does not change what happens to your password-reset mail after a complaint spike.

Why is the score higher than the other bulk-email entries?

The irreversibility number is the one that moved. The others are already at the ceiling on regulation and blast radius, and rightly so. Here the send is not only unrecallable in the usual way — it goes out under a name you do not control, on infrastructure whose reputation you cannot repair on your own authority, carrying a render you cannot correct. That is a step further along the same axis, and the score should say so.

sources
  • CAN-SPAM Act: A Compliance Guide for Business (FTC)
  • GDPR Art. 7 — conditions for consent
  • GDPR Art. 28 — processor obligations when you send on a client's behalf
did you build it?

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.

also on the regret index
Constant ContactABSOLUTELY NOT

That list was collected on paper at a trade show in 2019. You cannot prove consent for a single address on it.

MailchimpABSOLUTELY NOT

Sending bulk email is 5% code and 95% not getting your domain blacklisted forever.

MailerLiteABSOLUTELY NOT

The unsubscribe link is the regulated part, and it is the part you will implement last.

last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice