Customer.io

Promptfree, for everyone, and the only version there is

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

Copy

Do not rebuild this at scale — but be clear about which half you need, because they are very different.

**Live segments recomputed as events arrive** is a streaming problem rather than a scheduled job, and at real volume it is genuinely hard. **Multi-channel delivery** — email, push, SMS and in-app from one campaign — is four separate integrations, each with its own reliability and cost. Neither is a weekend.

WHEN TO KEEP PAYING
- Segments that must be current within seconds, driving time-sensitive messages
- Push and SMS alongside email, at volume
- Marketing people building campaigns without a developer

WHEN TO BUILD
- A few lifecycle sequences triggered by events from your own application, sent by email. That is most of what most products need, and the shape is covered under Loops elsewhere in this catalogue

THE TWO IDEAS TO TAKE WHATEVER YOU DECIDE

**One contacts table and one sends table.** Every message — campaign, sequence, transactional — is a row in the same place. That single schema decision is what lets you ask how many messages somebody has had today before sending another

**A frequency cap enforced in the send path**, per person per day and per week, for anything not transactional. Transactional always goes; a receipt is never suppressed by a marketing cap. This costs an afternoon and it is the difference between a product that communicates and one people mute

AND THE STOPPING RULES
- A sequence is stopped by an event, not only by finishing. 'Created first project' ends onboarding, and a sequence that keeps nudging somebody who already did the thing is the fastest way to be marked as spam
- Every enrolment records why it started and why it stopped
- One delivery row per person per message, written before sending, so a resume is exact and a duplicate is impossible

SEGMENTS WITHOUT STREAMING
- Compute them at query time from the event table. At a few million events that is fast, it is always current by definition, and it cannot go stale
- Materialise only the ones that are demonstrably slow, with the refresh interval visible next to the count so nobody mistakes an hourly segment for a live one

THE ONE-LINE VERSION
Buy it for streaming segments and four channels. Build it for email lifecycle — and take the frequency cap either way.