Your form needs an uncertain state, not just success and failure

An intricate system is required for form submissions, not just a binary success or failure outcome. When a browser sends an enquiry through a browser, the server records it. However, the response does not always reach the browser. The interface's message “Failed, try again” can be misleading because it assumes the browser already knows the outcome. To avoid this confusion, a disabled button can limit overlapping clicks on a single page instance. This does not resolve lost responses or duplicate work on the server.

The solution is to use a public form controller with four distinct states: ready, sending, received, and uncertain. The transition from sent to received only occurs when the HTTP response is successful, the JSON body contains the key "ok": true, and there is a UUID-shaped reference present. This UUID shape is a format check, not a proof of authenticity. The controller awaits the transport before signaling the "received" state. If the response is not received, the button remains disabled and the state stays at "uncertain".

This distinction between "received" and "uncertain" is crucial. While the former indicates the server has acknowledged the request, the latter suggests the acknowledgement could not be confirmed. The interface should not automatically resend the enquiry but instead inform the user that the receipt could not be confirmed and offer an alternative contact route. This approach is conservative, trading some convenience for the avoidance of unsupported claims about non-idempotent collection endpoints.

Only under documented pre-acceptance errors will the page reopen submission. The implementation recognizes four specific status/body pairs for validation, verification, size, and rate-limit rejections, all of which send it back to the "ready" state for a deliberate, corrected attempt.

This system separates engineering acceptance from sales reporting. A receipt counter can measure acknowledged submissions, but it should not be mistaken for "clients won". This counter does not account for everything that follows: fit review, reply, scope, agreement, and payment. Even when the source category is correctly implemented, it describes an observed referrer, not a proven first touch or AI recommendation.

To conduct a form review, start by documenting the evidence behind each message the user sees, then analyze what the interface does when that evidence is missing. The "uncertain" state can often provide more insight into the integration than a simple green success animation.