← All writing
Product engineeringSecurity

The safest form can be no form yet

Deferring a small public feature is an architecture decision when its abuse, privacy, and authority costs are not small.

A contact form looks like one input, one textarea, and one button.

Operationally, it is an anonymous public write API connected to a mail system and a human inbox.

The first release of this site deliberately has profile links instead. Nothing is “temporarily” sending mail from the browser, no provider key is embedded in a static build, and the page does not pretend that a visual component is a finished trust boundary.

Small interfaces can have large consequences

A real contact endpoint needs to decide:

  • which fields exist and how large they may be;
  • how spam, replay, and cross-recipient abuse are bounded;
  • whether the sender can influence headers, templates, or recipients;
  • what gets logged and retained;
  • what the user learns about mail delivery;
  • how provider failure affects the request; and
  • how submitted personal data is deleted.

Those are backend and operating questions. Styling the form first does not answer them.

Keep the static site authority-free

The public site is independently hosted so the writing and platform description survive a platform outage. Its build contains no mail credential and its browser code cannot choose a sender or recipient.

When the feature exists, the page will post a small fixed schema to one public human route owned by the console. That service can normalize input, impose body and source limits, check a honeypot and CAPTCHA, apply idempotency, and queue delivery without holding the request open for a mail provider.

The rest of the site will remain available if that endpoint is down. Profile links remain a valid fallback.

Reuse transport, not authority

The platform already has a pluggable transactional mailer. A future contact flow can reuse its send-only provider credential for one operator notification and at most one fixed acknowledgement.

The browser will not select the template. User content will not become trusted HTML. Delivery tracking will not become an identity signal. Contact records will not confer platform access.

Reusing a mail transport avoids another integration. It does not merge the contact form with enrollment or approval.

Deferral can preserve the right shape

Feature flags and placeholders are useful when the underlying contract is known. Here, shipping a disconnected imitation would encourage later code to grow around the wrong boundary.

Waiting keeps the desired architecture explicit: a static presentation, a narrow public API, bounded asynchronous mail, and minimal retention.

“Not yet” is not an excuse when it records what must be true before “now” becomes safe.