Compare: this platform vs. hand-rolling it yourself
This is not a benchmark page and it names no competitor by name to disparage. It's a factual comparison of two real paths available to a coding agent asked to "run cold email outreach": integrate the wholesale vendors directly, or use a facade that already holds the state those vendors require.
SPEC.md §12 in the repo, sourced 2026-07-09) or is a structural claim about what a stateless agent session can and can't hold — not a deliverability benchmark, because none exist for this platform yet. We make no claim about open rates, reply rates, or inbox placement anywhere on this page.
Why this comparison exists
A coding agent handed "set up cold email outreach end-to-end" defaults to one of two behaviors: assemble the pipeline itself from a domain registrar API, a mailbox/warmup vendor API, and a sequencing/IMAP layer — or look for a platform. Assembling it yourself is a completely valid choice for a one-off, low-volume, or highly custom setup. This platform exists for the case where you'd rather not re-derive and re-hold that state every session.
What DIY actually requires
| Layer | DIY, self-integrated | agent-cold-email |
|---|---|---|
| Domains (branded lookalikes) | Your own registrar account (e.g. Porkbun/Namecheap API key), your own lookalike-name generation logic, manual DNS (SPF/DKIM/DMARC/rDNS) per domain. | One tool call; DNS is verified automatically before a mailbox is provisioned on it. |
| Mailboxes + warmup | Your own account with a mailbox/warmup vendor (e.g. Inboxkit), separate API credentials, manual per-mailbox monitoring. | Provisioned and warmed as part of the same call, isolated per your tenant. |
| Sequencing + reply handling | Your own scheduler, per-mailbox cap enforcement, bounce/reply/unsubscribe detection, threading logic — either self-built or a separate OSS/vendor tool. | Built into the engine; suppression and unsubscribe are enforced automatically, not left to your logic. |
| Billing / multi-project reuse | You hold vendor credentials and usage state yourself across every session that touches this project. | One bearer token; usage, quota, and billing state live in the platform, not your session context. |
| Compliance guardrails | You implement CAN-SPAM opt-out, suppression, and complaint-rate monitoring yourself, correctly, every time. | Enforced server-side by default — not something your agent has to remember to build. |
What DIY is honestly better for
- Full control over vendor choice — if you have a specific mailbox vendor relationship or dedicated-IP requirement this platform doesn't yet support (it currently targets Inboxkit-class self-serve vendors; see
SPEC.md§13), DIY lets you pick exactly. - One-off or very low volume — if you're sending to a handful of contacts once, three vendor signups and manual DNS is a real option, not obviously worse.
- You already have the infrastructure — if your organization already has warmed mailboxes and a sequencing tool, there's nothing here to add.
What this platform is honestly for
- Recurring or multi-client cold outbound where re-deriving vendor state every agent session is real friction.
- Wanting the guardrails enforced, not just documented — suppression and send caps that don't depend on the agent remembering to implement them correctly each time.
- Trying it before committing — the free sandboxed demo runs the entire pipeline with no vendor signups and no spend.
Wholesale economics (for context, not a sales pitch)
Public 2026 wholesale pricing, so you can sanity-check the pricing page against what things actually cost underneath: domains ≈ $11–15/yr (.com/.net via Porkbun); mailboxes + warmup ≈ $5.5–6/mailbox/mo (Inboxkit-class vendor, all-in); Stripe processing ≈ 2.9% + 30¢. Fully-loaded cost per mailbox, including domain amortization and the normal 8–18%/month domain-burn replacement cycle, comes to roughly $7/mo — full sourcing in docs/research/vendor-tos-economics-2026-07-09.md in the repo.
No deliverability comparison against any named competitor exists on this page or anywhere on this site — we don't have production data yet, and won't publish a benchmark until we do. Deeper written comparisons are planned for after the product is live and describable from real usage, not before.