How it runs
Built like infrastructure, because it runs while you sleep.
Built and run by Statistique.
With 57,475 unmailable, the engine declined to contact about three quarters of the people it could have. The restraint is the part we engineered.
Where it runs
On a small VM you control.
The engine is self-hosted in your own cloud account. Your order history stays there. On the first brand a full run peaks at 13 to 14.4 GB of memory.
Per-consumer API keys.
Every consumer of the engine's API gets its own key, validated at the proxy and revocable on its own, behind two rate-limit zones.
The nightly build
Never touches the live database.
It takes an online snapshot copy, rebuilds against the copy, then swaps the two atomically. The API serves yesterday's data right up to the moment tonight's is ready.
Health poll, rollback, one retry.
After the swap the service is polled for up to 60 seconds. If the check fails, the previous database is put back automatically, the job fails loudly, and a single retry follows 10 minutes later, at most once a day. The failure mode is one bad night serving yesterday's data, not downtime.
Refuses to merge bad data.
If a field the subscription logic depends on is under 5 percent populated, the run aborts rather than corrupt the canonical history. Every job checkpoints after each phase and resumes after a crash.
The sender
Refuses stale data.
If the eligibility table is more than 20 hours old it declines to send and exits red, and it re-checks the 21 day cooldown against the live send log on every fire.
Dry-runs unless explicitly enabled.
It sends only when sending is switched on, a key is present and every campaign resolves to a metric. Shipping the code sends nothing; going live is a deliberate configuration act.
Idempotent events.
Each event carries a sha256 of organisation, customer, campaign, day and product, so a same-day re-run cannot double-send.
Adaptive rate limiter.
8 workers. The pacer speeds up 3 percent after every success and halves on a rate-limit response, honouring the retry hint, so it finds your account's real limit without anyone hardcoding the tier.
A daily cap, ranked by expected value.
Daily cap 1,250, a configuration value. When more people are due than the cap allows, the queue is ranked by calibrated probability times the value of the action. On a July due-universe of 25,922, ranking by probability alone would have sent 0 subscription emails out of 7,000; by expected value it sent 132.
Your controls
Three profile properties you can filter on.
Which Unlapse audience a customer is in, when Unlapse last emailed them, and a kill-switch. The first two keep your own campaigns and the engine's out of each other's way, so the control group is not contaminated and nobody gets both voices in the same week. The third pauses a customer, or everyone, with one property.
Weekly unmailable crawl.
Every Sunday evening the unsubscribed, suppressed and bounced list is re-crawled from Klaviyo (about 3.5 hours, a 400,000 row sanity gate, the previous list kept on failure). On the first brand, 57,475 scored candidates were unmailable on 21 Sep 2026 and are never sent.
Two test suites, green.
Standalone suites for the payload contract and for the sender: holdout stability, the cap, same-day idempotency, the expected-value ranking flip, pacing and graceful degradation on an older database.
Both send guards shipped in September 2026. Since 7 Sep 2026, zero customers have been re-sent inside 21 days, checked on the 21 Sep 2026 snapshot.
Tell us about your store.
Bring your engineer. We will walk through the VM, the keys and the guards before anything is switched on.