A Voice-Note Contact Form on a Fully Static Website

You can test this one without taking my word for anything. The button in the corner of this page — Message Alex — is the system described below, running in production. Press it, hold record, and say something. What you get back is the transcript of your own voice, with your email and website already filled in if you said them.

The site itself is a fully static Astro build with no server. Everything here runs in a single Cloudflare Worker on a separate subdomain, with Groq doing the speech and extraction work.

Why a voice note at all

The people this site is written for — owners of established service companies — describe their problem far better out loud than in a form field. Ask them to type and you get “need a new website.” Ask them to talk for ninety seconds and you get the actual situation: what the current site does wrong, which services matter, what happened with the last agency.

A text box collects the short version. The question was whether the longer version could be collected without asking anyone to install, sign up, or schedule a call.

The other half is unglamorous: a voice note that arrives as an audio file is a task, not a message. It cannot be skimmed, searched, or read on a phone in a queue. Whatever captured the speech had to also turn it into text before it reached my inbox.

How it works

Recording and sending are two separate steps

This is the design decision the rest follows from.

Transcription happens on upload, before the visitor submits anything. That costs a wait of a few seconds — but it means the transcript is not a byproduct filed away somewhere, it is the draft the visitor then edits. Speech-to-text gets names and company names wrong; letting someone fix their own name before it reaches me is worth more than saving them the wait.

It also means an abandoned recording is exactly that. Nothing is emailed until the form is actually submitted.

The email is text first, audio second

The note arrives as plain text: the message, the fields, the page it came from, the country. Underneath is one line with a link to hear the original recording, valid for thirty days.

The reply-to header is set to the visitor’s address when one was given or spoken, so replying works without copying anything out of the body. Tone, hesitation, and emphasis stay available in the recording for the cases where they matter — but reading comes first.

Architecture

The site is static and stays static. That was a constraint worth protecting: static pages are fast, cheap, and cannot break in the ways a server can.

The browser talks to a different origin than the page it is on, which makes CORS part of the design rather than an afterthought. Requests from the site’s own origins are allowed; requests carrying no origin at all — a click on a playback link inside an email client, for instance — are also allowed, because that is a legitimate path that no browser will label.

Documented in depth

Reaching everyone

Without JavaScript, the contact form is an ordinary HTML form that posts to the Worker and redirects back to a URL fragment, where a CSS rule reveals the confirmation banner. No script runs at any point. The voice recorder is not available in this mode, but sending a message is.

On iPhone, Safari records in a different audio container than Chrome does. Both are accepted, along with two more formats, because a visitor should never be told their phone is unsupported.

When transcription fails entirely, the recording still uploads, the note still sends, and the audio link still works. The transcript is simply empty. Every AI call in this system is allowed to fail without taking the message with it — the point is to deliver a lead, not to demonstrate a model.

Keeping it from being abused

A hidden field is present in the form that no human ever sees. Bots fill in every input they find, so a submission with that field populated gets a cheerful success response and is silently discarded — no error to learn from, no signal to adapt to.

Uploads are bounded at both ends: too small to be speech is rejected, too large is rejected, and only four audio types are accepted. Field lengths are capped. A submission with no way to reply at all is refused.

Playback links carry no signature and no expiry parameter. The link is the credential: a random name long enough to be unguessable, with age checked against the file’s own upload time on the server. There is nothing in the URL to tamper with.

Automated rate limiting is not built. Volume is currently low enough that the honeypot and size limits are doing the work, and adding a limiter before there is abuse to shape it against would be guesswork.

What is live today

This system runs in production on this very site — the widget on this page is it. The one item not built is automated rate limiting, and it is marked as such.

What we got wrong first

Outcomes

Operational, not measured. No conversion or volume figures are claimed, because none have been tracked over a defined period.

• A visitor can describe their situation in the way that suits them, without typing it.
• Notes arrive readable and searchable, with the original audio one click away when tone matters.
• Replying works directly from the email, with no copying.
• The marketing site stayed fully static, with all dynamic behavior in one small, separately deployed service.
• Every AI step can fail without costing a lead.

Where this pattern fits

Anywhere the visitor knows more than the form is able to ask, and typing it out is the thing stopping them:

The reusable parts are the structure, not the subject: transcribe before submit so the person can correct it, verify anything a model extracts against the source, and let every AI step fail without losing the message.

Who built this

Alex Taranov mapped the workflow, designed the data model and architecture, and oversaw implementation. AI-assisted tooling supported the coding; the product decisions, review, testing, and final responsibility stayed with Taranov Digital.

About Alex