The Intake Form That Failed Silently for Five Weeks

This site runs a structured intake form on roughly 3,800 pages. A visitor who wants to hire me answers a short series of questions about their matter, clicks submit, and sees a confirmation telling them the intake went through and a reply is coming.

For roughly five weeks, that confirmation was false.

The form posted its data to a server route that had never actually been implemented. Every submission failed. The failure was invisible in both directions: the visitor saw a polished success message and waited for a reply that was never coming, and I received no notification that anyone had tried to reach me at all. Nobody complained, because from the visitor's side there was nothing to complain about. The site said everything worked.

Nobody reported it. That is the defining feature of this class of failure: no complaint, no bounce, no error email. The visitor assumes the lawyer ignored them. The lawyer never learns the visitor existed.

The bug surfaced during a code-verified audit of the site's conversion infrastructure, run with an AI coding agent (Claude Code) working under my direction. The audit had one operating rule, the same rule I apply to legal citations: no claim gets believed until it is verified against the primary source. For code, the primary source is the live system, not the documentation and not the comments.

The agent traced every lead-capture surface on the site from the client side to the server code that was supposed to receive it. One path did not match: the intake form posted to a route the server never implemented. The project notes said a handler existed. The client code assumed it existed. The live deployment said otherwise, and the live deployment is the only witness that counts.

Before the finding was treated as real, it was confirmed three separate ways: a test submission against the live route (it failed), a read of the actually-deployed server code (no handler present), and GA4 event history (submit events firing for weeks with no corresponding notifications). Only then did "the form looks fine" become "every submission for about five weeks was lost."

The repair had two halves, and the second one matters more than it looks.

First, the missing server-side handler was written and deployed on the Cloudflare Worker that runs the site's backend. Intake submissions now land the way every other lead channel here does: an email to me via Resend, plus an instant Telegram alert to my phone. Nothing exotic, just the boring, reliable plumbing that should have been there from the start.

Second, the false success message was removed. If delivery ever fails again, the visitor now sees honest failure copy: a plain statement that the submission did not go through, with a prefilled email fallback so they can reach me anyway. A form that fails should say so. A confirmation that fires whether or not anything was delivered is worse than no form at all, because it actively stops people from trying another channel.

Within minutes of the fix going live, a genuine inquiry from a prospective client arrived through the repaired pipeline. I will not say anything more specific than that, because the details belong to the person who sent it.

But the timing proved something no dashboard could. Demand had been flowing through the broken pipe the entire time. The lost intakes in the GA4 data were not an abstraction: the very first real-world test of the repaired route was not a test at all. It was a real person with a real legal question who, a day earlier, would have received a false confirmation and then silence.

A same-day fix is worth little if the same class of bug can quietly return. So the same day, the site's automated health monitoring gained a canary: a scheduled check that probes the intake routes and can tell the difference between a route that exists and validates input and a route that is simply missing. If a future deploy ever breaks the intake pipeline again, the break shows up in monitoring immediately, not five weeks later in a painful audit.

I am publishing a bug in my own infrastructure because the discipline that caught it is exactly what I offer other firms, and candor is cheaper than pretending nothing ever breaks. Four things this incident demonstrates:

• AI as supervised infrastructure, not an oracle. The coding agent did the tracing and the drafting; I directed the audit, reviewed the changes, and made the judgment calls. That is the same supervision the California Rules of Professional Conduct expect when a lawyer relies on any nonlawyer assistance.
• Verification before belief. Every factual claim in the audit was checked against the live system before anyone acted on it. Documentation lied; the deployment told the truth. I hold AI-assisted legal research to the identical standard: no citation goes out until it is verified against the authoritative source.
• Instrumentation pays for itself. Because the site fires analytics events on every intake step, the outage could be dated and sized precisely. Without that, the honest answer to "how bad was it?" would have been "no idea."
• Honest failure states. Software that tells a prospective client something worked when it did not is not a cosmetic bug for a law practice. It is a client-communication failure. Every system I build now fails loudly and offers a fallback.

One boundary worth restating: the AI here wrote code. It did not and does not give legal advice, and it is not an "AI lawyer." It is infrastructure, supervised the way I would supervise any assistant.

This is the kind of audit and build work I do for other firms through my AI implementation practice, and the client-facing systems I build are on display in the AI legal workrooms showroom. If a form, portal, or intake pipeline is quietly load-bearing for your practice, it deserves the same code-verified scrutiny.