I Stopped Designing Forms for Only Humans

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?
Can I let my agent register me for the workshop while I sleep?
Can the team's automation submit the vendor onboarding form without us copy-pasting?
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 explicit final approval.

Real chat flow looks like this:

> このフォームを公開してください。

公開前に確認が必要な項目があります。以下の2つのURLを確認してください。
- フォームのプレビュー
- サンクスページのプレビュー
確認できたら、以下も教えてください。
- 重複回答防止 - メールアドレス単位 / クッキー（同一ブラウザ）/ 設定しない
- プライバシーポリシー - URLはありますか？なければ「不要」で進めます。

And then, after the user works through it:

設定がすべて揃いました。最終確認です。
- アクセス: URLを知っている人のみ
- 重複回答防止: メールアドレス単位
- プライバシーポリシー: https://formlova.com/ja/privacy
- 自動返信メール: 有効
「公開する」と返信いただければ即座に公開します。

That is the moment I realized the product was no longer about the human in front of the form, or even about the human in front of the chat. It was about whoever happens to be on the other end of the tool call. The same gate runs whether the operator is a person, a Claude session, a Cursor session, or an automation that runs at 3 a.m. The contract is the same.

Once that was the contract, treating the respondent side as also potentially non-human stopped feeling like a stretch. It felt like the same idea applied one layer outward.

Why this is a good wedge for an indie

I keep checking whether this is actually a real wedge, or just a story I am telling myself.

There are a few markers that make me think it is real.

The incumbents in the form category did not pick this shape. Most of them are still optimising for the human submitter and the human admin. That is a perfectly reasonable position. It is also a position that leaves a flank open.

The shape can be built by a small team. It does not require a new payment rail, a new identity system, or a new browser. It requires careful design choices at the form layer.

The shape compounds. Each form designed this way teaches the agent ecosystem how forms should behave. Each MCP-connected client that submits successfully reinforces the pattern.

The shape is hard to copy with a sticker. A competitor cannot ship "AI agent support" by adding a setting. The submitter assumption has to be baked into the field model, the validation contract, the submission API, and the bot defence policy.

The shape is also pricing-resilient. FORMLOVA's plans run Free, Standard 480 yen / month, and Premium 980 yen / month. The agent posture sits across all three. The Free plan still gets unlimited forms, unlimited responses, CSV/Excel export, response search and status management, and basic workflow tooling. The agent-readable surface (semantic field names, declared validation, intent-id submission, structured confirmation) is part of the product, not a paywalled feature. Standard adds the operator-side conveniences (auto replies, reminders, conditional emails, scheduled actions, detailed analytics, imports, CRM sync, email branding). Premium adds team operations (mailing lists, bulk sends, step emails, paid forms, audit logs, Stripe Connect). None of those are gates on whether an agent can fill the form properly.

That last point is what makes me comfortable spending years on this. The interesting moats are the ones that look like nothing from outside.

What I had to give up

Choosing this wedge meant giving up a few habits.

I stopped competing with form builders on visual customisation as the main axis. The visual layer is still important, but it is not the differentiator any more.

I stopped framing AI in the product as "AI helps you build the form." That story is true, but it is not the wedge. The wedge is on the other side of submit.

I stopped treating the dashboard as the centre of operator gravity. The dashboard still exists, because some tasks are clearer there. But the canonical operator surface is the chat, because the chat is where agent integration is natural.

I stopped designing as if every legitimate submission came from a person reading the page. That single change reshaped a surprising number of downstream choices.

I also stopped pretending FORMLOVA never calls an LLM. The original positioning was clean: "FORMLOVA does not call an LLM for normal usage; the orchestration happens inside your MCP client." That is still mostly true. The honest caveat is that the sales-pitch classification on inbound responses runs a lightweight server-side model. It costs about $0.0002 per response, it is opt-in per form, and it does not run on paid event responses. I would rather state that small caveat clearly than carry a clean-but-false slogan.

What I tell other founders looking at form-adjacent ideas

If you are thinking about building in form-adjacent space, my honest suggestion is to look at the submitter assumption first, not the maker assumption.

A lot of AI-era form pitches start at "we use AI to help you build the form." That market is crowded and the moat is thin, because the AI part is mostly the AI client, not the form product.

A smaller number of pitches start at "we make the form behave well for the new kinds of submitters." That market is less crowded, the moat compounds, and it gives you a reason to exist that does not evaporate when the next AI client ships.

This is not the only wedge in the category. The post-submit response operations wedge is also real, and it is the one I wrote about last time. But the agent submitter wedge is the one I think will look obvious in 2028 and slightly weird right now.

I would rather be slightly weird now than obvious later.

There is one specific failure mode I keep watching out for: confusing "more AI exposure" with "more submitter quality." If your form fails an agent submitter because the field labels are not semantically stable, no amount of LLM features will fix it. Conversely, if your form is honest with the agent reader and quiet about the AI features in the UI, you will still capture the segment. The wedge is the contract, not the marketing.

What FORMLOVA is doing about it

Concretely:

The form schema exposes stable semantic field names, so an agent can map "company" to the right field even if the visual layout changes. The 29 field types each carry a stable id, a semantic name, and a snapshot of the label that was active when the response was collected.

The submission API accepts a submitter-assigned intent id, so retries do not create duplicates. The capacity check uses a SELECT ... FOR UPDATE + INSERT transaction so the intent id and the capacity decision land atomically.

The submit response is structured, so the agent can read what was recorded without depending on a toast. Auto-reply state, notification state, and downstream classification state live on the response record, not in a notification log.

The bot defence treats "agent acting on behalf of a person" as a legitimate lane, not a fraud lane. Cloudflare Turnstile remains in front for unknown sources. Sales-pitch classification (about $0.0002 per response, OpenRouter-hosted) sits behind submit so legitimate-looking but sales-shaped responses can be routed instead of refused.

The form is operable through MCP, so AI clients like Claude, ChatGPT, Cursor, and Windsurf can talk to it directly. The MCP layer has 129 tools across 25 categories. Eleven of those tools, plus publish_form, sit behind HMAC-signed confirmation_token gates with a 5-minute TTL. The model cannot bluff its way past an externally-visible operation.

The conversational mode lets a submission come through a conversation, not only a rendered page, while keeping the same canonical record. The form is still the canonical store; the entry shape is plural.

None of those are magic. Each one is a small choice. The bet is that the sum of those small choices is what the next few years of form work actually look like.

What I am still not claiming

I keep two short lists pinned near the top of the build log. The first is the boundary list, lifted directly from a Show HN review I did with a more experienced founder earlier this year.

I do not claim "zero LLM cost." The sales-pitch classification path uses a small server-side model, $0.0002 per classified response, opt-in per form.
I do not claim "works with any MCP client." I say "MCP-compatible clients" or "clients that support custom MCP connections," because some clients still gate custom MCP connections behind enterprise plans or specific runtime modes.
I do not claim "tested every competitor." I have read product docs and run small experiments against a handful. The position is not "we beat them all"; the position is "this wedge has been mostly empty."
I do not claim "chat is faster for every task." It is better for cross-step operational workflows. Dashboards remain better for scanning and visual inspection.
I do not position FORMLOVA as replacing Google Forms for quick surveys. Different shape, different audience.
I do not ask anyone to upvote the project anywhere. I write about the work, then go back to the work.

The second list is the strongest critique I expect, also lifted from the same review: "this is MCP hype wrapped around a form builder." I concede the first half (chat is not for every visual task) and answer the second half (the actual MCP surface is post-submit operations and agent-friendly submission contracts, not yet another visual builder).

I would rather pin those lists where I can see them than carry a thesis that needs the caveats hidden.

The honest summary

I am not trying to remove the human submitter. Most submissions are still going to come from a person reading a page.

I am trying to stop building forms that quietly punish the cases where someone trusted an agent to do the submission for them.

That is the wedge I picked.

I would rather build for the submitter the market is moving toward than only for the one it is moving away from.

The submit button is not the finish line.

It is the first moment the product becomes operational, for whoever is on the other end of the tool call.