What to market now (positioning that matches reality)

Unique Positioning

“The deliverability‑first email engine with enterprise guardrails and MCP‑ready AI—EU‑friendly today, EU‑resident path available.”

“More inbox, fewer incidents.”

We keep your campaigns compliant with current mailbox sender requirements (authenticated sending, one‑click unsubscribe, and complaint‑rate guardrails), block broken sends before they happen, and provide graceful failover so key flows never miss.

Why this positioning? Deliverability + reliability are the outcomes teams feel immediately — and they don’t require hard EU‑residency claims yet. We keep the MCP‑first angle (AI that acts through governed tools) as a differentiator.

The 10 benefits email teams care about most

1. Pass the 2024+ rules by default

• Outcome: Fewer rejections/spam placements.
• Proof: Gmail requires SPF, DKIM, DMARC, one‑click unsub, and keep spam < 0.30%; bulk = 5,000+/day. We ship opinionated wizards and guardrails around these. (Google Help)
• Feature: Auth setup (SPF/DKIM/DMARC), alignment checks, DKIM ≥ 1024/2048, PTR, TLS, one‑click headers (RFC 8058), “send block” if non‑compliant. (Google Help)

2. One‑click unsubscribe (right, every time)

• Outcome: Lower complaint rates; inbox eligibility.
• Proof: One‑click per RFC 8058; Gmail enforces for bulk senders. (IETF Datatracker)
• Feature: Automatic List‑Unsubscribe + List‑Unsubscribe‑Post headers, 48h processing SLA.

3. Complaint‑rate autopilot

• Outcome: Stay below Gmail’s 0.30% threshold.
• Feature: Domain/IP reputation monitor, adaptive throttling by destination, “high‑risk cohort” exclusion, auto‑pauses on spikes. (Google Help)

4. No broken sends

• Outcome: Avoid costly mistakes.
• Feature: Preflight checks — DNS/auth, link validation, image‑to‑text ratio, domain age/health, blocklists, preview & seed‑inbox tests.

5. Reliability & failover

• Outcome: Critical flows never stop.
• Feature: Multi‑provider routing with health checks and automatic failover (e.g., route across EU‑capable senders where available).

6. List health built‑in

• Outcome: Fewer bounces, higher inbox placement.
• Feature: Bounce/suppression handling, inactivity pruning, verifications, captcha/double opt‑in helpers.

7. A/B & holdouts that protect reputation

• Outcome: Learn faster without burning trust.
• Feature: Guarded ramp‑up, cohort randomization, statistical stop rules.

8. MCP‑first, governed AI

• Outcome: Faster creation without risking brand/compliance.
• Feature: Agents call tools (compose_email, segment, ab_test, schedule_send) with scopes, rate‑limits, approvals, and audit logs.

9. Developer‑grade observability

• Outcome: Find and fix deliverability issues quickly.
• Feature: Postmaster integrations, per‑domain dashboards, webhook export to SIEM.

10. EU‑friendly operations (today)

• Outcome: Lower transfer risk & latency for EU users.
• Feature: Pin Vercel functions to EU regions; minimize PII in transit; DPF/SCCs for cross‑border transfers.

Rethinking Email: a Developer‑First, Unified, and Trustworthy System

1) The problem, from first principles

Job to be done: Help product teams compose, send, observe, and govern email—across both transactional flows (e.g., verification, receipts) and marketing campaigns—with deterministic outcomes: did it send, deliver, bounce, get clicked, or lead to an unsubscribe?

What’s broken today (deconstructed):

• Fragmentation: Different tools, UIs, and models for “transactional” vs “marketing” create duplicate work and inconsistent behavior.
• Glue code everywhere: Webhooks, retries, deduping, unsub handling, and “resend” logic are hand‑rolled repeatedly—and often differently—per team.
• Misleading metrics: Apple Mail Privacy Protection makes opens unreliable; teams still over‑optimize for them.
• Unsafe environments: Dev and staging accidentally hit real inboxes; logs can leak PII.

Constraints we accept:

• Spam complaints are a hard budget; deliverability is everyone’s concern.
• Privacy realities (e.g., Apple MPP) mean clicks and conversions are the signals that matter.

2) The one simple idea

Email as a Deterministic Ledger

Instead of “send + hope + parse some webhooks,” we treat each email as a transaction with a lifecycle recorded in a canonical, append‑only ledger. This ledger becomes the single place to see, trust, and act on what happened—live.

We collapse the entire domain into a tiny, human‑sized algebra:

• Template – versioned content with typed data.
• Audience – a single person or a segment, with consent.
• Send – the intentional act (with an idempotency key); schedule, throttles.
• Message – the concrete rendering that was (or will be) delivered.
• Event – the truth stream: sent, delivered, deferred, bounced, complaint, click, unsubscribe.

And two guardrail objects:

• Policy – deliverability/compliance rails (auth must be green; bulk requires one‑click unsub; complaint budget; warm‑up; throughput).

What this unlocks:

• No more webhook glue in your app. The system normalizes events into the ledger automatically.
• Compliance by construction. Bulk sends automatically include one‑click unsubscribe and will not go if auth or rules aren’t satisfied.
• Privacy‑sound analytics. We elevate clicks and conversions; opens become an “estimate,” not a KPI.

3) Why now

• Mailbox rules tightened (e.g., one‑click unsubscribe for bulk) and privacy changed (opens are noisy). A new baseline is required: compliance and clicks first.

• Modern building blocks exist:

  These let us collapse the stack into a few primitives with correctness built in.

4) What we are building (in plain language)

• A unified system where transactional and marketing share the same mental model—no separate stacks, no duplicated features.

• A live timeline for any email, user, or campaign that answers “what happened?” without leaving the app.

• Guardrails that refuse risky sends: unauthenticated domains, missing one‑click unsub for bulk, unhealthy complaint rates, unsafe dev/staging sends.

• A developer experience that feels obvious:

  1. Define a template,
  2. Call Send with an idempotency key,
  3. Watch the ledger update in real time,
  4. Use Resend as a policy (not a custom flow).

Our stack, at a glance (no deep detail):

5) Assumptions we explicitly challenge

• “Transactional and marketing must be separate systems.” No. One model handles both; policy decides the behavior and constraints.

• “Open rate is the KPI.” No. It’s noisy. We prioritize clicks and conversions, and show opens as estimates.

• “Webhooks are the only source of truth.” No. The ledger is the truth; webhooks are just a transport into it.

• “Resend = send again.” No. Resend is a state machine with abuse controls and token rotation.

• “Dev must send real emails.”

6) What teams get (outcomes that matter)

• Confidence & clarity: Every send has a trace; every outcome is visible; every policy is enforced.
• Speed: From “blank repo” to “first compliant, tracked email” in minutes, not days.
• Fewer incidents: Guardrails prevent unauthenticated bulk, missing unsub, dangerous complaint spikes, and dev-to-real inbox accidents.
• Less glue code: Idempotency, retries, resends, suppression, and one‑click unsub live in the platform.
• Better decisions: Analytics center on click‑through and conversion—signals that matter to product and growth.

7) Our core beliefs & values

1. Correctness by default The safest behavior should be the easiest path. If a send isn’t compliant or authenticated, it doesn’t go.

2. Transparency > mystery A single ledger and live timeline replace “check five dashboards” and guesswork.

3. Privacy‑respecting analytics Measure what’s real—clicks and conversions—and label the rest honestly.

4. Safety in every environment Dev/staging never hit real inboxes unless explicitly allowed. Logs don’t leak PII.

5. Everything in code, UI for the right edits Types, schemas, and flows live in code; a safe UI lets non‑engineers edit content within guardrails.

6. Small, composable primitives

7. Portability and no lock‑in

8. Operational empathy Deliverability isn’t “ops only.” Developers get proactive feedback (auth checks, complaint budgets, warm‑up) and can prevent issues before they happen.

8) Why this will work

• It aligns with the new reality. Compliance and privacy are non‑negotiable; our defaults enforce them.
• It removes accidental complexity. One ledger replaces custom webhook mappers, ad‑hoc suppressions, and brittle resend code.
• It scales in capability without growing in complexity. The same primitives serve single‑user flows and million‑recipient campaigns; policy adjusts the rails.

9) How we will measure ourselves

• Time to first compliant send (from init to delivered with auth + one‑click unsub where applicable).
• Zero duplicates across retries (idempotency).
• Complaint rate kept below budget by default (guardrails and throttles).
• Ops load reduction (no custom webhooks, fewer support escalations).
• Developer satisfaction (does the model feel obvious and trustworthy?).

10) The near‑term roadmap

• M1 – Resend & Campaigns: Resend policies (TTL/cooldown/caps), scheduled sends, throughput controls, warm‑up, complaint guard.
• M2 – Multi‑channel (optional): Reuse the same ledger for SMS/push where it makes sense.
• M3 – Self‑host option: For teams that need full control and data residency.

11) The promise

We’re building the simplest possible way to send email the right way: one model, one ledger, live truth—with guardrails that keep you safe and signals that move your product forward.

This is email that respects developers, honors users, and meets the web where it is today.