Brevo

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me email sending that replaces Brevo — and know exactly why this is ALMOST.

The application is a fortnight. **Deliverability is not.** What you are paying for is a warmed sending platform with people watching complaint rates, shared reputation you did not have to build, and pricing by send rather than by contact. You can run the software; you cannot short-cut the reputation. Read the warm-up section before deciding.

STACK
- Node 20+ with Fastify, server-rendered HTML
- SQLite through better-sqlite3, WAL mode
- A bulk sending provider — you still need one, and that is the honest position. What you avoid is the per-contact pricing on top
- A worker for sending, separate from the web process
- Caddy in front

THE DATA MODEL
- lists, contacts, segments — segments as saved rules, evaluated at send time and never stored as a member list
- contacts: id, email, attributes_json, status, confirmed_at, unsubscribed_at, bounced_at, complained_at, source, consent_text, consent_at, ip_hash
- campaigns and deliveries: one delivery row per contact per campaign, written before sending, which is what makes a resume exact and a duplicate impossible
- transactional: id, template_id, to_hash, payload_json, provider_ref, status, sent_at, opened_at, bounced_at
- templates: id, kind, subject, mjml_source, text_source, version
- suppression: email_hash, reason, at — global, across every list, forever
- automations and automation_sends, so nobody receives the same step twice

THE ONE RULE ABOUT REPUTATION
- Transactional and marketing mail must not share a sending domain. A password reset that fails to arrive because a campaign got complaints is a support disaster
- Use a subdomain for each, with separate SPF, DKIM and DMARC records, and separate provider streams if the provider allows
- Warm slowly: a new domain sending twenty thousand messages on day one goes to spam and stays there. Start in the hundreds and double over weeks. Put the schedule in the README
- Watch the complaint rate. Above a fraction of a percent the provider suspends you, and that is the failure that ends the project
- Suppress hard bounces immediately, complaints permanently, and anyone who has not opened anything in a very long time. A list full of dead addresses is what destroys reputation

SENDING
- The worker claims a batch with a lease, sends, and records the result. A crash resumes exactly where it stopped
- Idempotent per contact per campaign, because the row already exists
- Rate limited to what the provider accepts, with backoff on throttling
- A test send required before any campaign, and a confirmation showing the recipient count and the segment — the mistake everybody makes once is sending to the wrong list

THE MESSAGE
- Built with MJML or tables and inline styles, with a plain-text alternative generated from the same source
- Personalisation with a default for a missing value, so nobody is greeted as 'Hi ,'
- One-click unsubscribe with no login, plus the List-Unsubscribe headers the large providers now effectively require
- Preview at phone and desktop width, and in the client that renders with the Word engine

SMS, HONESTLY
- If you need it, it is a provider, a per-message cost, and in most countries a registered sender identity with an application process. It is not code, it is paperwork, and it is worth checking before promising it

REPORTS
- Sent, delivered, opened, clicked, bounced, complained, unsubscribed, per campaign and over time, computed from rows at query time
- Open rate labelled as unreliable, because privacy proxies pre-fetch images. Clicks are the number that means something

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, PROVIDER credentials, FROM_ADDRESS, SESSION_SECRET, HASH_SALT
- Migrations on boot, each once; nightly backup off the machine — this holds your list, which is the asset
- Health endpoint checking the provider and the bounce feed

WHAT MATTERS MOST
Separate domains and the suppression list. Get those two right before the first send, because reputation is the one thing here that cannot be fixed afterwards.