Building Summit Tracker: A PIN-Gated Insurance CRM Mockup on Cloudflare Workers
An afternoon, a Cloudflare Worker, a PIN gate, and 24 production-quality mockup views — the case study of how preview.usasummitagency.com got built with Buddy by ahmeego.
The Summit Agency — a Globe Life family of insurance agencies in Gilbert, AZ — needed to evaluate a CRM concept with leadership before deciding whether to buy a vendor or build internally. The catch: the mockup had to look real (because hand-wavy whiteboards don't survive an investor conversation), live on a real domain (because clicking through a Figma file kills the magic), and stay private (because broadcasting an unreleased product idea is bad).
So we built and deployed Summit Tracker — a 24-view insurance agency CRM mockup — on a single Cloudflare Worker, behind a PIN gate, on the company's real domain. Total build-and-ship time: one afternoon. Total monthly cost: $0. Total page weight: 271KB raw, ~33.6KB gzipped. Total surface area visible to the public internet without the PIN: zero.
This is the case study: what we built, how the gate works, the regression where we accidentally left it wide open for 27 minutes, and what Buddy unlocked along the way.
Live Coach Floor view at preview.usasummitagency.com — KPI row, variance heatmap (agents vs team baseline), live activity feed, today's leaderboard. The default landing view for Owner and Manager roles.
The brief
The Summit Agency wanted to make a binary call: buy a CRM or build one? Most agency CRMs in the insurance space (NowCerts, Radius, AgencyBloc, plus Salesforce add-ons) are competent at the basics but rarely fit the daily reality of an agency floor. Specifically, the founder wanted to test five claims with the leadership team:
Coaching belongs front and center — not buried two clicks deep behind reports. Variance vs the team baseline should be the homepage, not "ALP MTD" alone.
The mobile experience is the producer's actual interface — agents are between appointments, in cars, at door-knock breaks. The mobile home screen should do exactly one thing: log activity in three taps.
Role-based scopes should be obvious in the UI — Producers shouldn't even see teammate deals or audit logs. The system should silently scope every screen to the role the user is in.
1:1 coaching needs auto-flagged talking points — the system should know when an agent's close rate is slipping and surface that to the manager before the 1:1, not as a quarterly surprise.
Conversation intelligence is going to redefine training — talk-to-listen ratios, AI-extracted action items, objection patterns. This needs to be a first-class view, not a buried Gong integration.
That's a lot to communicate via a slide deck. The fastest way to get leadership to a real reaction was to put a tappable mockup in their hands — on the agency's real domain, locked down, looking like an actual product.
Stack decision
This is a single-page mockup with 24 views, no real backend, no persistent state. The deploy story didn't need much, but the gate did. We landed on:
Layer
Choice
Why
Hosting
Single Cloudflare Worker
One wrangler.toml, one entrypoint, asset binding for the static HTML. Total deployable: under 300KB.
Domain
preview.usasummitagency.com
Real subdomain on the company's existing zone, attached via Workers custom-domain binding. Cloudflare auto-creates the DNS route since the zone is on Cloudflare nameservers.
Auth
Server-side PIN gate
The Worker checks for a signed cookie (summit_auth=1) on every request before serving the asset. No client-side gate — those are trivial to bypass.
Session
HMAC-signed cookie
30-day TTL, HttpOnly, Secure, SameSite=Strict. Survives reloads without storing anything in KV.
Lock screen
Edge-rendered HTML
Worker returns a small lock-screen HTML when no valid cookie is present. Same edge as the protected asset, no extra latency.
Design system
Bricolage Grotesque + Manrope + JetBrains Mono
Dark surface (#0E0E10), gold/red/emerald/blue accents, grain overlay, mono numerics. Visual language for "operations tool, not consumer app."
The 24 views
One single HTML file, 10,143 lines, 271KB raw, 33.6KB gzipped. The sidebar nav switches between 24 distinct sections via show/hide CSS. No SPA framework, no routing library, no build step beyond what the Worker bundler handles. Just discipline about scoping each section.
My Day view for Marcus Reed (Producer). The big card on the right is the AI-prepared lead context for the 3:00 PM appointment with the Hayes family — pulled from the lead notes, structured into "Lead with", "Discovery", "Records to break today" blocks. This is the screen the agent looks at while putting on his shoes.
The full set of 24 views, grouped:
Floor (3): Coach Dashboard, My Day, Leaderboard
Sales (4): Pipeline, Leads, Add Lead, Sequences, Power Dialer
Coaching (3): 1:1 Sessions, Conversations, Goals
Service (2): Application Status & Underwriting, Commissions
Role preview (3): Sign-In Screen, Agent Portal · Marcus, Add Lead
Role-based scopes
The Permission Matrix on the Users & Teams view is the source of truth. Five roles — Owner, Manager, Producer, Recruiter, Trainee — each with explicit can-do/can't-do rules. The Agent Portal preview shows what every Producer sees the moment they sign in: their numbers, their pipeline, their leaderboard position, their commission — never their teammates'.
Agent Portal — the producer's home. Note the explicit role banner ("You're viewing as Marcus Reed, Producer") and the scope statement: he can add leads, log activity, see his commissions and pipeline, but can't see teammate deals or open the audit log. Role transparency is the design value.
Why this matters: in agency CRMs, "scope drift" is the silent killer of trust. A producer accidentally sees a teammate's commission pipeline; word gets around; the system loses the floor. The Agent Portal as a separate view, with the role explicitly named in the topbar pill and the scope rules visible in a side panel, is a deliberate trust signal.
Leaderboard with metric pivots (Dials / Appts Set / Appts Sat / Close Rate / ALP Written) and time-window pivots (Today / Week / Month / Quarter / YTD). The podium is the marketing surface; the full standings table below is the operational tool.
The mobile PWA
The single screen no agent will use on desktop. The home screen launches at "Today's stats + big log buttons." Hit a button, get a haptic, you're back to selling. Push notifications wake agents for stale leads, appointment reminders, leaderboard movement. Works offline; logs queue and sync when network returns.
Mobile Quick-Log — the field interface. 3-tap rule: home screen does ONE job (log activity), everything else is one swipe away. PWA, not native, so it ships in 60 seconds and avoids App Store review delays. Lives at log.thesummitagency.com in the production version.
The PIN gate
This is the part that almost broke. The intent was simple: server-side check, no client-side gate, signed cookie for the session. The Worker logic looks like this:
// worker entry (simplified)
export default {
async fetch(req, env) {
const url = new URL(req.url);
// 1. Lock screen if no valid cookie
const cookie = req.headers.get('cookie') || '';
const valid = await verifyCookie(cookie, env.AUTH_SECRET);
if (!valid && url.pathname !== '/auth') {
return renderLockScreen(); // small inline HTML
}
// 2. Auth endpoint accepts PIN, sets signed cookie
if (url.pathname === '/auth' && req.method === 'POST') {
const { pin } = await req.json();
if (pin !== env.PIN) return new Response('Bad PIN', { status: 401 });
const sig = await sign('1', env.AUTH_SECRET);
return new Response('{}', {
headers: { 'set-cookie': \`summit_auth=\${sig}; Path=/; HttpOnly; Secure; SameSite=Strict; Max-Age=2592000\` },
});
}
// 3. Authenticated path: serve the asset
return env.ASSETS.fetch(req);
},
}
The sign-in screen mockup — not the real PIN gate (that's a separate edge-rendered HTML), but the production sign-in concept the agency wants to ship: email/password + MFA, Workspace/Microsoft SSO, IP + device + location stamped to the audit log on every login.
The 27-minute regression
This is the part of the story I'm not allowed to omit. The first deploy attached the custom domain and shipped the gate. Or so I thought. Roughly 27 minutes later, while testing from an incognito window, I realized I was getting straight to the Coach Dashboard with no PIN prompt at all.
What went wrong: Cloudflare's default Worker-with-assets routing serves static files before running the Worker handler in some configurations. My gate logic was written assuming the Worker always ran first; instead, the static asset matched the request path and got returned directly — bypassing the gate entirely. From the moment the custom domain was attached (around 8:06 PM PT) until I caught and fixed it (around 8:33 PM PT), preview.usasummitagency.com was open to anyone with the URL.
The fix was a one-line change in the Worker config to flip not_found_handling from default to "single-page-application" — which makes the Worker run first on every request, before any static asset match. After the fix and a redeploy, every unauthenticated request gets the lock screen, full stop.
Two takeaways:
Always test unauth before considering a gate "done." Open an incognito window, hit the URL, confirm the lock screen renders. The thing I assumed would block requests was being silently routed around. Trust nothing without a positive verification.
Audit-log everything that hits the gate. The post-fix version stamps every request (auth or unauth) with IP, user-agent, timestamp, and gate verdict. So even if the gate were bypassed again, we'd have a record of who hit which path while it was open.
Numbers in production
Final state: 24 distinct views in a single 271KB HTML file, gzipped to ~33.6KB at the edge. Custom domain preview.usasummitagency.com on Cloudflare Workers, gated with a server-side PIN check (HMAC-signed 30-day cookie). Every unauthenticated request returns a 200 with the lock-screen HTML; only valid sessions reach the asset binding. Hosting cost: $0/month. Total build-and-deploy time including the regression-and-fix: under 4 hours.
What Buddy + ahmeego unlocked
Three things would not have been possible at this scope and quality without the agent assist:
Translating a Claude artifact into a deployed product mockup. The original mockup arrived as a 10K-line HTML artifact from a different conversation. Buddy slotted it into a Worker, attached the asset binding, configured the custom domain, and surfaced the auth-gate flaw on the first incognito test — all without me having to context-switch.
The "wide open for 27 minutes" honesty. The fix was easy. The harder thing was being clear about what the bypass meant and how to prevent it from happening again. The audit-log addition wasn't asked for; Buddy proposed it as the right safeguard for next time.
One Cloudflare account, one wrangler.toml, one deploy. No third-party auth provider, no analytics SaaS, no email vendor. The whole stack is reviewable in 60 lines of TypeScript plus the static HTML asset. Maintenance is exactly proportional to the number of moving parts: small.
If you want one of these
If you've got a product idea you need to put in front of leadership without burning months on a real build — or a sales artifact that has to look real but stay private — this is exactly the work Buddy by ahmeego is built for. Cloudflare Workers + asset binding + an auth gate is the smallest possible production stack for a gated mockup, and we can ship one in an afternoon.
Open Buddy → Or reach out if you want me to scope a build like this for your own brand.
Article 19 in this series is the companion piece — a 77-page production insurance brokerage site (goodlifeinsurancegroup.com) shipped end-to-end on Cloudflare with Buddy in a weekend. Same playbook, different output shape.
Subscribe if you want each one in your inbox. And if you've got questions about your own version of this, my inbox is open.
— John
Sources & references: Direct observation from building preview.usasummitagency.com with Buddy on May 18, 2026. Cloudflare Workers and Workers Assets documentation. The original 24-view CRM mockup arrived as a Claude artifact from a separate conversation; integration into a Worker, custom domain attachment, the PIN-gate logic, and the post-incident audit-log additions were all done with Buddy. All screenshots are live captures of the production mockup.
