I Stopped Designing Forms for Only Humans - Indie Hackers

Join

Like

Bookmarks

Comments

Report

When I started building FORMLOVA, my mental model of the user was the same one every form product has used for twenty years.

A person reads the page.

A person fills the fields.

A person clicks submit.

We then talk about conversion rate, mobile completion, drop-off, and whether the placeholder copy is friendly enough.

For most of the form category history, that picture was fine. Sometimes it was even the only honest picture, because the agent reader did not exist outside of crawlers and screen readers.

The picture has been changing under my feet for the last year.

The submitter is no longer always the person whose name is in the name field.

This post is about how that shift changed what I built, what I refused to build, what I would tell another founder looking at form-adjacent ideas right now, and the few things I would still be careful not to claim.

What I noticed in conversations

The signal did not show up in dashboards first. It showed up in the way people talked.

Some operators started saying things like:

Can my assistant fill this signup for me overnight?<br>Can I let my agent register me for the workshop while I sleep?<br>Can the team's automation submit the vendor onboarding form without us copy-pasting?<br>Can Claude / ChatGPT just do this signup using my information?

These were not edge requests. These were people describing what they already wanted to do.

The interesting thing is that the form on the other side was always designed for a human submitter. So the agent had to pretend to be a human. Sometimes it succeeded, sometimes it bounced off a captcha, sometimes it filled the wrong field, sometimes it submitted twice on retry, sometimes it triggered duplicate prevention.

Every time that happened, the form owner did not see a failure.

They saw a slightly lower conversion rate from a segment they did not know existed.

That is when the wedge clicked.

I had already been positioning FORMLOVA around a different wedge: the work that starts after submit. The two-line version of that thesis is:

Most form tools stop at creation. FORMLOVA starts after publish.

That thesis was already paying off in operator-facing conversations. The "agent submitter" wedge is the second half of the same coin. It is not "the form is the product" or "operations after submit is the product." It is "the form is one of several surfaces a non-human reader may also be operating, and each one of those audiences needs an honest contract."

The bet I am making

The bet is small, but it has a few moving parts.

First, the share of legitimate form submissions made by agents on behalf of a person is going up, not down. Whether the agent is a desktop AI client, a browser agent, a workflow automation, or a computer-use model, the direction is the same.

Second, forms designed for only human submitters are going to silently underperform with that segment. Not visibly. Not via a clear error. Just via quiet drop-off no one attributes correctly.

Third, fixing this is not an API problem. Most agents fill forms by reading the rendered surface, not by hitting a separate REST endpoint. The fix has to live in the form itself: field naming, validation contract, idempotency, confirmation, bot defence posture.

Fourth, the products that respond to this shift do not need to remove the human experience. They need to add a second, equally honest interface for the agent reader. The same form, two readers.

That is the bet behind the FORMLOVA posture. Operate the form from a chat. Expose the form as a tool over MCP. Make submission idempotent. Treat agent submitters as a legitimate audience, not as a fraud category.

The specific thing that made me commit to the bet was not a customer interview or a TAM analysis. It was a publishing flow.

The publishing flow that convinced me

When I implemented publish_form in FORMLOVA, I originally wrote it as a single tool. "Publish this form." Done.

A few weeks of internal usage made the cost of that decision visible. A casual prompt to "publish the form" from a chat would not pass through any of the things a careful publisher actually does: opening the preview, opening the thank-you preview, confirming the duplicate prevention setting, confirming the privacy policy URL, confirming the final state before something becomes public.

So I rewrote publish_form as a server-side review state machine. It does not publish on the first call. It returns the current review state, the next required action, the list of missing requirements, and two preview URLs (form and thank-you). Preview confirmation only advances when the preview URL has actually been opened. The privacy policy URL has to be set (or explicitly waived). The duplicate prevention setting has to be picked between "email-based," "cookie-based," and "none." Only when every condition is met does the tool issue a fresh confirmation_token and accept the...