Iterable

Promptfree, for everyone, and the only version there is

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

Copy

Understand the size question first. **This category is bought for volume and channel breadth.** If you send a few hundred thousand emails a month across one or two channels, the buildable version below is genuinely enough. If you are orchestrating across four channels at scale with contractual guarantees, keep paying.

STACK
- Node 20+ with Fastify
- SQLite through better-sqlite3, WAL mode
- Worker processes for the journey engine
- A relay for email, a provider for push and SMS
- Caddy in front

THE DATA MODEL
- profiles: id, external_id, attrs_json, channels_json with per-channel consent and timestamps
- events: id, profile_id, name, props_json, at — one table, new behaviours are new names
- journeys: id, name, version, definition_json, is_active
- enrolments: id, profile_id, journey_id, journey_version, node_id, next_at, entered_at, exited_at, exit_reason
- sends: id, profile_id, journey_id, node_id, channel, template_version, at, provider_ref
- experiments and holdouts

THE JOURNEY ENGINE
- A directed graph of nodes: wait, send, branch on a condition, split for an experiment, webhook, exit
- **Detect cycles and refuse to activate a journey containing one**, unless there is an explicit cap. An accidental loop at scale sends a very large number of messages very quickly
- Every enrolment carries the journey version; editing a live journey never moves people already inside it
- Idempotency per profile per node, a lease on the queue, retries with backoff, a dead-letter with replay

TEMPLATES AND DATA
- Templates versioned, with the version recorded on every send. **A report about a campaign is meaningless if the template it refers to has since been edited**
- Personalisation with a required fallback for every field
- A render preview against a real profile, showing every channel's output

THE RULES THAT PROTECT PEOPLE
- One frequency cap across every channel, not one per channel
- Quiet hours in the profile's timezone, enforced globally
- Consent per channel, recorded with source and time, and honoured separately — **SMS consent is legally distinct from email consent nearly everywhere**
- A suppression list checked before every send on every channel

MEASUREMENT
- A permanent global holdout receiving nothing, so the programme's total effect is measurable rather than assumed
- Per-journey experiment splits assigned deterministically, reported with confidence intervals and a minimum sample
- Unsubscribe and complaint rates per journey, shown as prominently as the revenue

OPERATIONS
- A per-journey kill switch effective in seconds
- A dry-run mode that evaluates a journey against real profiles and sends nothing
- Queue depth, oldest pending enrolment and dead-letter size on a health endpoint, with alerts

WHAT MATTERS MOST
Versioned journeys and enrolments, a global frequency cap, and a kill switch. Those three are what make an engine like this safe to run at any size.