Not just fast. Built to show the thinking.
The job is to rebuild pindrop.com for the AI era — “fast, personalized, intelligent, and equally discoverable by humans and AI agents.” This is a working concept of that, and a look at the decisions behind it: a Cloudflare-native stack, edge personalization, AI-native experiences, and an honest performance story including a regression I caught and fixed.
One stack, all Cloudflare
Static-first by default; only the routes that need a server render on-demand at the edge. Content is git-versioned (no SaaS CMS bill), AI runs on Cloudflare's own GPUs, and leads hand off to Pindrop's real system, Pardot.
Why this over WordPress or Webflow?
All three are valid — the right call depends on the mandate. For one that's explicitly about speed, AI-native experiences, and edge personalization, owning the stack wins.
WordPress
pindrop.com today. Familiar, huge plugin ecosystem, marketing autonomy — but a real perf ceiling (LCP ~15s here), and AI-readiness is bolted on (the Yoast-default llms.txt).
Webflow
Designer-friendly and fast to launch. But hosted lock-in + per-seat pricing, a perf ceiling on rich pages, and limited room for edge logic, custom AI, or a real CRM handoff.
This — Astro + Cloudflare
Own the stack: top performance, edge compute (A/B, RAG, forms run at the edge), AI-native by default, git-versioned content at ~$0, no per-seat SaaS. More dev-centric to author — the trade for control.
vs. pindrop.com today
The current site is WordPress; this rebuild is Astro on Cloudflare. Same content, mobile Lighthouse, measured the same way. The gap that matters most is LCP — how long until the main content actually shows.
Mobile Lighthouse, simulated throttling. pindrop.com measured 2026-06.
Variants decided at the edge
A/B variant and industry persona are assigned in middleware on the Cloudflare
Worker — server-side, before a byte ships. No client-side Math.random(),
no flash of the wrong headline, consistent for crawlers, and the assignment is
available server-side to attach to the lead payload.
Grounded answers, leads that carry context
The “Ask Pindrop” chat is retrieval-grounded on site content — queries embedded with Workers AI and matched against a Vectorize index — then generated by Workers AI (Claude-ready via a one-env swap). The demo form does a clean CRM handoff: variant, persona, and first-touch UTM map to Pardot custom fields (and persist to D1 behind the leads dashboard), so conversion-by-variant reporting falls out in Salesforce.
RAG chat
Lead handoff
Discoverable by agents, on purpose
The mandate says the site should be “equally discoverable by humans and AI
agents.” pindrop.com already serves an llms.txt — but it's the
Yoast default, listing event pages and summits rather than the product story,
and there's no AI-crawler posture in robots.txt. Small gap, big
leverage for a company whose product is AI.
pindrop.com today
- llms.txt — auto-generated by Yoast; lists a Gartner event, a summit, the homepage
- robots.txt — blanket allow, no
Google-Extended/GPTBot/ClaudeBotrules - structure — WordPress markup, no agent-facing brief
this rebuild
- llms.txt — hand-curated: mission, product line with ®, 99% / 5B proof points, and explicit “how agents should use this site”
- robots.txt — explicit AI-crawler directives + sitemap
- structure — semantic HTML, JSON-LD (Organization + WebSite), server-rendered content
One asset, two outputs
The interactive “spot the deepfake” voiceprint is built on PixiJS (WebGL) — the same engine the ad ecosystem uses to author playable and HTML5 creative. So it isn't a throwaway hero: the same scene can export to ad platforms like Meta and Google, giving the team a reusable interactive-creative asset. On-site it stays lazy-loaded — the ~470KB renderer is dynamically imported on scroll, so it costs the page zero LCP.
One person, the whole stack
A pure software engineer with a math background who loves the browser. This whole thing — front-end, edge compute, performance, the AI features, the CRM handoff, content modeling, and this writeup — is one person's work. That range is the role itself: developer, web strategist, data, and marketing-systems in a single seat — “as comfortable writing code as diagnosing Core Web Vitals or telling a stakeholder what moved pipeline.”
Integration, especially, is just input and output — with a math and systems foundation, a new platform is the same problem in different clothes. Salesforce is the case in point: I worked it from the C# SDK in 2007–2008, and again as a sales engineer at Snowflake. So the Salesforce/Pardot handoff here is routine — and the same holds for whatever analytics, CRM, or marketing tool comes next.
What's real, what's a seam
The chat runs on Workers AI and swaps to Claude with one env var. Retrieval runs on Vectorize — queries embedded with Workers AI, matched against the indexed site content (the full KB is the fallback, so it's never broken). Leads persist to D1 behind the auth-gated dashboard. The Pardot handoff is modeled to their real form-handler pattern — the integration shape, not deep operator experience. Analytics is wired end-to-end — GA4 events, Web Vitals RUM, per-CTA tracking with persona + variant context — pointed at a placeholder property; the wireup is demonstrated, live with one real ID. Every number here was measured, not asserted.
← Back to the demo