The mobile widget's email submission was wired to the wrong endpoint.

The mobile step called requestMeasure() — an endpoint designed for the full desktop flow that requires an order ID, a full name, and a reCAPTCHA response. The mobile flow has none of those things. It has a tenant ID, an email address, and a street address. Three fields sent to an endpoint expecting five. Silent failure.

A dedicated POST /api/wizard/request-mobile-link endpoint now handles exactly what the mobile flow needs: find or create a customer from the email, find or create an order from the address, send a branded "Continue Your Quote" email with a link back to the full wizard, and notify the admin about the new lead. Four operations, one lightweight endpoint, no reCAPTCHA baggage.

The email got a proper Mailable class and a branded Blade template instead of a raw text string. "Continue Your Quote" with the company logo, the address they entered, and a deep link back into the wizard where they left off.

The fix was architectural, not technical. The mobile flow was borrowing an endpoint built for someone else. Giving it its own endpoint — purpose-built, minimal validation, right-sized — turned a broken feature into a working one.