Collect only what the task needs
The public question form is intentionally direct: the question and an optional reply email. The contact form asks for a name, an email, and a message. These are separate entry points because a request for help and a private communication are not always the same thing. Neither form needs your login password, a payment-card number, or a recovery phrase. Keep the submission focused on the issue. More personal information is not a substitute for better context, and a simple form should not become an excuse to collect everything.
Understand the delivery stage
The production package uses Netlify-compatible form markup. A deployed site must have form detection and submission handling enabled for that route to work. Notification destinations and access to stored submissions are deployment settings, not something a visual mockup can verify. A local preview deliberately does not send the form as though it were the live service. That distinction protects against the appearance of a successful delivery when no delivery occurred. The message should be treated as received only when the deployed service has actually accepted it.
Keep the transport separate from the answer
Sending a question is one operation; producing a useful response is another. A successful form submission does not mean an AI has completed a task, a human has read the message, or a reply is already on its way. The delivery layer should provide a clear result and preserve enough context for the next stage. If a submission fails, the interface should not present the failure as success. If a reply email was omitted, the system should not suggest that it has a private channel back to you. Clear state is more valuable than decorative reassurance.
Keep private operations private
Public pages explain the system and provide the entry points. Deployment settings, notification accounts, service credentials, and operator administration belong outside that public surface. Nothing in a publicly downloadable page should function as a private credential. HTTPS on the deployed site protects the browser-to-site connection, but it is not a promise of end-to-end encryption or unlimited confidentiality. Share only what is appropriate for the channel. The goal is practical and specific: move a well-formed request to its intended destination, make failure visible, and avoid exposing the machinery that should remain private.
Submitted, received, reviewed, and answered are different states. Treat them differently.