QuickLead

Inspiration

Local service businesses lose high value jobs when an inquiry waits too long. QuickLead was built around one narrow promise, stop losing customers because you replied too late.

What it does

QuickLead turns inbound service inquiries into a human reviewed response and follow up workflow. Urgent leads rise first, an AI assisted reply draft is prepared, the owner can edit and explicitly approve it, follow up stays visible, and the appointment or outcome is recorded.

The real pilot remains invite only. Judges can use a separate public synthetic demo with no account. It stores nothing, calls no QuickLead API, Supabase, Google, or OpenAI endpoint, and resets on reload.

How we built it

The private pilot uses React, TypeScript, Vite, Cloudflare Pages Functions, D1, Supabase Auth, and OpenAI backed drafting with a labeled safe fallback. It includes owner/staff authorization, tenant isolation, idempotent intake, optimistic concurrency, audit events, retention cleanup, responsive UI, and guarded deployment/rollback workflows.

The public judge demo is an isolated in memory reducer with deterministic fixtures. It demonstrates prioritization, owner editing, explicit approval, follow up state, exact one synthetic booking, metrics, timeline updates, and reset behavior without crossing into production systems.

How Codex and GPT-5.6 helped

I chose the local service wedge, narrow V1 scope, mandatory human approval, private pilot boundary, visual direction, support-only Google policy, deployment approvals, and credit discipline.

Codex with GPT-5.6 accelerated the D1 and authentication architecture, implementation, responsive demo, Google security design, deterministic tests, release gates, runbooks, evidence, and debugging. The repository changelog separates QuickLead's earlier prototype from material work committed after Build Week opened.

Challenges

The hardest part was making a convincing judge experience without exposing credentials, customer data, a real mailbox, or unrestricted production mutations. We also had to preserve exact one provider behavior, human approval, tenant boundaries, accessibility, mobile layouts, deployment rollback, and honest evidence.

Google infrastructure and authenticated Pub/Sub were configured, but the final real-provider smoke was not run because the QuickLead Supabase project became unhealthy during an unresolved Supabase incident. No synthetic provider mutation began. The Google path remains testing-only, and we do not claim Google verification, CASA certification, or real mailbox readiness.

Accomplishments

• A deployed no login judge demo with deterministic reset and zero provider/persistence calls.
• A working invite only production pilot with human reviewed drafting and follow-up.
• 89 unit, 145 integration, and 184 browser checks on the final Worker candidate.
• Authenticated Pub/Sub staging, guarded deploys, immutable deployment IDs, and rollback points.
• A private judge repository shared with both required judging identities.
• A public YouTube demo with audio and no copyright issues.

What we learned

Shipping safely is a product feature. Human approval, exact one behavior, isolated demos, truthful provider status, and reproducible evidence make an AI workflow more credible, not less ambitious.

What's next

Run the bounded provider smoke after Supabase is healthy, complete any required restricted-scope verification and security assessment, then validate QuickLead with a small paid pilot measuring response time and booked work. Voice, billing, full CRM replacement, and broad integrations remain intentionally out of scope.

Built With

• cloudflare
• openai
• playwright
• react
• supabase
• typescript
• vite