WiFiScanner AI SDR 2.0 — scaling the send side

1.0 proved the pipeline end to end on one shared Workspace inbox. 2.0 is entirely about what feeds that pipeline's inbox-pool table and gmail-oauth secret — more sending identities, spread across more domains, with real visibility into whether any of them are burning reputation. Nothing about ICP discovery, Clay sourcing, personalization, or the approval gates changes; send-scheduler.ts already round-robins across whatever's in the inbox pool, so this is additive capacity, not a rebuild.

30 inboxes × 10 sends/day = 300/day baseline. That's a useful checkpoint to be explicit about: this is well below the 1,000–5,000/day range where dedicated cold-email infra operations live, and most of what makes their tooling complex (bulk inbox marketplaces, per-alias throttling consoles, managed warmup-as-a-service) is solving a problem this scale doesn't have yet. The operating principles those operations use — don't run inboxes at the edge of their limit, isolate domains so one bad one doesn't take the rest down, watch signal and rotate out underperformers rather than trying to "fix" a domain — hold at any scale, and are what 2.0 actually borrows.

Two ways to add sending capacity, with different isolation properties:

Recommendation for this scale: a handful of separate root domains (not 30 — one per 5-6 inboxes), each registered through Route 53 like trywifiscanner.com was, each with its own SES-independent SPF/DKIM/DMARC (cold sends don't go through SES at all, so this is just Workspace + Route 53 DNS, no SES identity needed per sending domain). Reserve the actual product domain (wifiscanner.com) for the real site only — never for sending, same as today.

No third-party inbox marketplace (Hypertide-style vendors sell pre-warmed inboxes in bulk) — staying AWS + Google Workspace only means this stays a manual-ish loop per domain:

1. Register the domain (Route 53), point MX/SPF/DKIM at Google Workspace per Google's setup docs.
2. Verify the domain in Google Workspace, create user accounts (one per sending identity — Workspace's per-domain user limits depend on the plan tier).
3. Enable 2-Step Verification per user, generate an App Password per inbox.
4. Bulk-paste email,app-password,dailyCap into the admin form's Sender Inboxes section — it writes each into the shared gmail-oauth secret and creates the inbox-pool row, same mechanism as today's single inbox.
5. Let new inboxes age before adding real send volume — see warm-up note below.

Researched as an alternative to the manual provisioning loop above — API-only, no one operating Smartlead's own dashboard. Smartlead doesn't replace the pipeline's brains (Bedrock, the two approval gates, DynamoDB state stay exactly where they are); it would replace the mechanical send/receive layer mailer.ts currently owns, in exchange for managed inbox warmup and a reputation dashboard — the two things flagged as an honest gap in the sections above.

What Smartlead does that we could build ourselves

What only Smartlead offers

Cons

Framing: because it's strictly API-driven with no manual dashboard operation, it fits the "everything through the Lambda pipeline / admin form" philosophy even though it isn't AWS-only — think of it as AWS + Google Workspace + Smartlead-as-a-managed-API, not a platform switch. Worth a real trial-account spike (14-day free trial, 2,500 email credits) to confirm the two unconfirmed items above before deciding between this and the manual-provisioning path.

The smallest-footprint option of the three. Unlike Smartlead, MailReach doesn't want to own sending or replies — it's a reputation-building layer that rides alongside inboxes already in the inbox-pool table. Nothing in the existing pipeline changes: mailer.ts, send-scheduler.ts, reply-poller.ts, personalization, both approval gates, and the DynamoDB schema all stay exactly as built. The only additions are (1) registering each inbox with MailReach via API using the same App Password credentials already generated, and (2) pulling its per-inbox reputation score ("Heat Score") into admin-status.ts — directly filling the Postmaster-Tools-shaped gap flagged above, without OAuth.

What's missing, compared to the other two options

Recommendation: lowest-risk way to close the reputation-monitoring gap without touching a single line of the working send/reply pipeline — but it solves a narrower problem than Smartlead (reputation only, not real-time prospect replies), and needs a real 30-inbox quote before assuming it's the cheaper of the two paid options.

Clarifying which system sees what, since it's easy to check the wrong dashboard:

Postmaster Tools has a JSON API, but it's OAuth-based — the same complexity tradeoff already declined once when this build moved from Gmail-API-OAuth to SMTP+App-Password. Recommendation: treat Postmaster Tools as a manual check-in per domain for now, and only build the API integration if reply-rate data (which is easy to automate) starts suggesting a specific domain has a problem worth digging into. (Smartlead's own reputation dashboard, or MailReach's Heat Score API, would each cover most of this table without a separate Postmaster integration — see Options B and C above.)

An audit of the current stack against what's actually deployed: Lambda, DynamoDB, API Gateway, EventBridge Scheduler, Secrets Manager, SES, Bedrock, S3, Route 53. Grouped by what each addition actually fixes, not just "nice to have."

Alerting — was zero coverage, now built

Reliability & data durability

Security & delivery

Branded links

Every approval/unsubscribe/booking-adjacent link this pipeline emails now reads as go-development.trywifiscanner.com instead of a bare execute-api.amazonaws.com host — via the same CloudFront-in-front-of-the-API fix that made WAF possible above, not a direct API Gateway custom domain (which can't take WAF).

Architecture-level — bigger lift, deliberately not taken

The ops platform's /provision/test page lets you pick a domain (or have Bedrock suggest a few) and click through a simulated provisioning run — registering → DNS → Workspace → inbox → ready — without any real side effect. Deliberately not a variant of the real Step Functions workflow: it never calls Route 53 or the Google Admin SDK, since a domain suggested or typed here was never verified to exist, let alone be owned. Everything it writes stays in the ops platform's own ops-domains/ops-audit-log tables, tagged source: "test-suggested" and shown with a (test) badge — never the pipeline's real inbox-pool table, which is the only one send-scheduler.ts/reply-poller.ts ever read. wifiscanner@trywifiscanner.com stays the only real sender regardless of what's provisioned here.

• Provision above the daily target, not at it. Some headroom (not a specific multiplier prescribed here) means a domain that trips a signal can be pulled without volume dropping to zero that day.
• Domains are disposable, not something to nurse back to health. If a domain's reply rate craters or Postmaster flags it, pull its inboxes from the pool (status: paused — already supported) rather than trying to fix reputation in place.
• New inboxes aren't send-ready on day one. Let a new domain/inbox sit for a couple of weeks — sending small, low-risk volume or none at all — before ramping it into full rotation. How long is a judgment call, not a fixed rule; watch reply rate as the signal rather than a calendar.
• Pace, don't burst. The existing MAX_SENDS_PER_INVOCATION + per-inbox dailyCap in send-scheduler.ts already do this — worth remembering it's there rather than raising caps aggressively when volume needs to grow.
• Reply rate over open/click tracking. 1.0 already made this call (see architecture.html, "Deliberately not built") — it holds at this scale too.

Unsubscribe and approval links currently point at the raw execute-api.us-east-1.amazonaws.com URL. API Gateway HTTP APIs support a custom domain name directly — an ACM certificate plus a Route 53 alias record pointed at the API's regional domain, no CloudFront required unless caching or a WAF is wanted in front of it later. A subdomain like links.trywifiscanner.com would cover unsubscribe, ICP-approval, and reply-approval links in one change to apiBaseUrl().

Sending capacity (300/day) and Clay's lead-sourcing plan tier are separate constraints — a bigger inbox pool doesn't source more leads by itself. Worth checking Clay's plan limits against the 300/day target independently once inbox scale-up is underway; if sourcing can't keep pace, the extra send capacity just sits idle.