AEO Scorecard Connector

A public "get your free scorecard" product. The analysis engine digests homepage positioning, selects competitors, fans out across data APIs (Moz and other SEO/authority sources, plus search context), and renders a personalized AI search readiness scorecard. It generated $700K in pipeline in a few weeks. This page is about the plumbing I built around that engine so thousands of signups couldn't crash it, double-bill it, or expose it.

DEEP DIVE ? LEAD MAGNET INFRASTRUCTURE

production ? Vercel Next.js Postgres Cron jobs HubSpot Forms Moz + SEO APIs Slack auth Calendly webhooks

Heavy engine, public edge

The analysis engine takes a long time per company and costs real money every time it runs: it digests homepage positioning, picks competitors, hits external APIs (Moz and similar SEO/authority endpoints, search context), scores AI search readiness, and renders the scorecard views. None of that site-reading / competitor-picking is secret sauce — anybody can do those steps. Marketing wanted the whole thing as a public lead magnet. Putting a slow, expensive multi-API engine directly on the public internet is how you get abuse, double-billing, and timeouts.

The answer was a deliberately small connector that owns intake, queueing, storage, and projection — and explicitly does not own how the engine analyzes a company. Clear ownership boundaries meant the frontend designer, the backend owner, and I could all ship independently. What follows is the connector story, not a blueprint of the scoring product.

flowchart TD
  IN[Lead form + operator requests] --> Q[Connector queue]
  Q --> DEDUPE{Already running
for this domain?}
  DEDUPE -->|Yes| REUSE[Reuse it
no double billing]
  DEDUPE -->|No| ENG[Analysis engine]
  subgraph WORK["Inside a run"]
    SITE[Digest homepage positioning]
    COMP[Select competitors]
    APIS[Moz + SEO APIs + search context]
  end
  ENG --> WORK
  WORK --> CHECK[Periodic check-in
until done or failed]
  REUSE --> CHECK
  CHECK --> OUT[Public scorecard
+ team dashboard]

  style ENG stroke:#10b981,stroke-width:2px
  style OUT stroke:#8b5cf6

The check-in loop that keeps it healthy

In plain English: on a schedule, the connector checks on running analyses, revives ones that got stuck, gives up on lost causes, and feeds new requests to the engine at a pace it can handle. A burst of signups can never overwhelm it.

Never bites off too much: each check-in round is capped, so one slow response can't stall the whole loop.
Revives the stuck: analyses that sit "processing" too long get restarted automatically.
Gives up on lost causes: anything that never finishes gets marked failed instead of clogging the queue forever.
Meters the flow: only a fixed number of analyses hit the engine at once; the rest wait in line locally.
Never pays twice for the same company: if a run for that domain is already going or finished, new requests reuse it unless someone explicitly forces a fresh one.

flowchart LR
  WAIT[Waiting] --> RUN[Running]
  RUN --> DONE[Done]
  RUN --> RETRY[Stuck? retry]
  RETRY --> RUN
  RUN --> FAIL[Give up]
  WAIT -.->|paced| RUN

  style DONE stroke:#10b981,stroke-width:2px
  style FAIL stroke:#f59e0b

What the connector owns

Intake — public lead form into HubSpot, plus on-demand runs for SDRs / operators
Queue + health — dedupe, paced handoff to the engine, scheduled check-ins, failure handling
Outputs — public scorecard page for the prospect, team dashboard for status and follow-up
Loop-close — booking webhooks so a finished scorecard can turn into a demo on the calendar

One source of truth, two views

The analysis is stored once. Prospects see a public scorecard; the team sees status and follow-up context. The frontend builds against a stable, connector-owned shape, so the engine can change internally without breaking the lead magnet.

Locked down by default, spends money deliberately

The keys never leave the building: the public site talks to the connector; only the connector holds credentials to the expensive engine.
Development can't spend money: local/dev environments don't hit the paid engine unless deliberately switched on for a paid test.
Missing security config blocks deployment: production refuses to serve unprotected rather than shipping open.
Company-only admin access: the internal dashboard is gated to the team — no password database sitting around to breach.
Abandoned bookings become follow-ups: if someone starts booking a demo and doesn't finish, the team gets a Slack alert. An almost-customer is a sales signal, not silence.

"The connector's whole job is being boring: never pay twice, check on the slow thing, lock the public thing, and give the team one dashboard where nothing is mysterious."