Case study · an AI product, shipped

Division 6 AI Visibility Audit

A Claude-powered product that audits how AI assistants recommend local businesses — and shows each one how to become the answer. I designed it, built it, deployed it, and sell it. Here's the engineering behind it.

Role
Sole designer & engineer — end to end
Surface
Public product, admin CRM, delivery pipeline
Core
Claude API · web search & fetch tools · serverless
Status
Live & selling at division6.co
The problem

Customers stopped Googling. They ask AI.

Local businesses live and die by "best [what you do] near me." That search is moving from Google's ten blue links into ChatGPT, Perplexity, Gemini, and Google's AI Overviews — which return one answer, usually naming a handful of businesses. If AI doesn't name you, you're invisible exactly where the buying decision now happens, and most owners have no idea whether they show up or not.

The opportunity: a product that measures a business's AI visibility, proves the gap in a way the owner feels, and hands them the fix — priced as an easy first "yes" that opens the door to the real work.

What I built

A funnel that runs itself, from prospecting to paid delivery.

One system spans the whole commercial arc — find a prospect, prove the problem for free, take payment, deliver a premium report, and track it. Every stage is real software:

01

Prospector /api/find-businesses

Enter an industry, location, and radius; a Claude call with web search returns real local businesses ranked by their Google Maps / local-pack position, with ratings and review counts.

02

The "mirror" /api/generate-mirror

For any business, a two-step pipeline reads its own website for ground-truth identity, then runs one local search to find the competitors AI recommends instead — and writes a tailored cold-outreach email whose angle changes with the prospect's Maps rank.

03

Gated snapshot /r/<slug>

A private, password-protected page shows the prospect their AI-visibility gap plus a scope-of-work and a Stripe checkout. The teaser is built and encrypted on the fly.

04

Full audit /api/audit-*

On payment, a multi-step research → compose → publish pipeline produces a premium, plain-English report: a six-dimension scorecard, competitor analysis, and a step-by-step action plan. The same private link upgrades from teaser to full report.

05

Admin CRM encrypted dashboard

A gated admin lists prospects and clients, runs audits, tracks pipeline status and conversion dates, and copies ready-to-send delivery emails.

The hard parts

Where the real engineering was.

A demo is easy. Making an LLM product reliable, accurate, and economical against real-world constraints is the job. Four problems worth calling out:

Constraint · latency

Premium depth vs. a hard 60-second serverless ceiling.

Problem

A genuinely deep audit needs several rounds of LLM research with live web search — well over the 60-second hard limit a serverless function gets. Single-call attempts timed out (504s), especially on ambiguous inputs.

What I did

Decomposed the work into a chain of small, individually sub-60s calls orchestrated from the client (research → compose → publish; identity → mirror). Total wall-time can run minutes, but no single function ever approaches the ceiling — and each step retries independently. Reliability went from flaky to dependable.

Accuracy · grounding

The model confidently named the wrong city.

Problem

For a business with a common name, web search surfaced a bigger, same-named firm two states away — and the model adopted its identity, reporting the wrong city on a paid, customer-facing report.

What I did

Stopped trusting search for identity. I fetch the business's own website server-side (fast, deterministic) and hand that ground truth to the model, so name, city, and category come from the source of record. Search is then used only for the thing it's good at — finding competitors. The wrong-city class of bug disappeared.

Relevance · prompt design

Findings wandered off the customer's actual market.

Problem

Asked about competitors, the model drifted into national name-overlap and irrelevant firms — noise to a local business owner who only cares who's beating them in their own metro.

What I did

Retuned the system and task prompts to enforce local-only scope in four places, shaped the search as the customer would phrase it (best <category> in <city>), and passed the confirmed identity through so the model never re-derives it. Output became specific, local, and useful.

Trust · delivery

Paid reports had to be private, and payment had to unlock them.

Problem

Deliverables people pay for can't sit at a guessable URL, and the same link a prospect saw as a free teaser had to become the full report once they paid — without emailing new links around.

What I did

Client-side AES-256-GCM encryption (PBKDF2 key derivation, WebCrypto) gates every report; the server stores only ciphertext. One password-protected link serves the encrypted teaser before payment and the encrypted full audit after — state flips on the prospect record, the URL never changes. Stripe payment links carry the prospect id so payments reconcile automatically.

Throughout, I kept an eye on cost and latency as first-class design constraints — capping search counts, bounding how much of a page the model reads, and choosing effort levels per step — because an AI product that's slow or expensive per run doesn't survive contact with real usage.

Stack

Built with.

AI / LLM

Claude (Sonnet)Anthropic Messages APIWeb search & fetch toolsMulti-step orchestrationPrompt engineeringpause_turn handling

Platform

Node.js serverlessVercelSupabase / PostgresStripeWebCrypto (AES-GCM, PBKDF2)

Frontend

Vanilla JSResponsive CSSAccessibility (WCAG-AA)Client-side crypto gate

Product

Discovery & positioningPricing / funnel designReport & UX designCopywriting
Why it's an FDE case study

This is the job, end to end.

I found a real, painful customer problem, designed a product around it, and shipped working AI software against production constraints — latency, accuracy, cost, trust — then wrapped it in payments, delivery, and a CRM so it actually runs as a business. No handoffs, no six-month roadmap.

That's exactly what a Forward Deployed Engineer does inside a customer's world: understand the problem fast, build the thing, make it reliable, and make it stick.