Prompting AI to add forms / RSVP / contact UI without a backend (2026)

The AI tool generates the event microsite. The RSVP form looks great — name field, email field, attending dropdown, dietary preference, a submit button styled in your brand color. You preview it, fill in your own details, hit submit.

Nothing happens. Or the URL changes to ?name=test&email=test@example.com and the form clears. Or a console error appears about a 404 on /api/rsvp. The form has a UI; it has no path to actually receive the data.

The fix is to be specific in the prompt about which submission path the form should use, before the AI tool defaults to either a placeholder or an over-engineered solution.

Why the default goes wrong

AI builders are optimizing for two things at once: the visual design pattern of a form (which they know well) and the submission flow (which depends on the backend setup, which the AI doesn't have).

The defaults that show up:

• The form submits to nowhere. The <form> has no action attribute; clicking submit refreshes the page and clears the fields. Most generated forms ship this way.
• The form POSTs to an imagined endpoint. <form action="/api/submit">. Looks valid; the endpoint doesn't exist.
• The form pretends to submit and shows a fake success message. JavaScript intercepts the submit, fakes a delay, shows a green checkmark. Data goes nowhere.
• The form requires a full backend. The AI scaffolds a Node.js API route + database schema + email sending logic. Overkill for a single HTML file that just needs to collect RSVPs.

Each of these is solvable in the prompt by naming the actual submission path the form should use.

The three working shapes

1. mailto: form — simplest, lowest volume

The form's action is a mailto: link with the visitor's email pre-filled. On submit, the visitor's email client opens with a draft email to the form owner, containing the form data in the body.

<form action="mailto:host@example.com" method="post" enctype="text/plain">

Cross-tool prompt:

Add an RSVP form to this page. The form submits via mailto: — action="mailto:host@example.com", method="post", enctype="text/plain". No JavaScript needed; the visitor's email client handles the rest. Include a one-line note under the form: "Submitting opens your email client to send the RSVP."

Right fit: personal events, low-volume contact forms (a freelancer's "get in touch" page), proof-of-concept pages where formal submission flow doesn't matter yet.

Trade-offs: works in <50% of cases in practice (mobile email clients don't always handle this cleanly; visitors without a configured email client see nothing happen); not great UX for "real" form needs.

2. Third-party form service embed — most common right shape

Form services (Formspree, Tally, Web3Forms, Getform, Basin) handle the submission backend; you point the form's action at their endpoint, the data flows to your email or their dashboard.

<form action="https://formspree.io/f/YOUR_FORM_ID" method="POST">

Cross-tool prompt:

Add an RSVP form that submits to a Formspree endpoint. Use action="https://formspree.io/f/<form-id-placeholder>", method="POST". After submit, redirect to a thank-you confirmation either via Formspree's built-in next page or via a _next hidden input. Include a placeholder comment in the HTML: "Replace <form-id-placeholder> with your actual Formspree form ID — set up free at formspree.io".

The same pattern works with Tally (<iframe> embed of a Tally form), Web3Forms (similar action attribute), and most other form services. Each ships a free tier sufficient for personal events and small landings (50-500 submissions per month typically).

Right fit: most cases. Event microsites, AI product landings, freelancer contact pages, beta signup waitlists. The form service is invisible to the visitor; the data lands in the form owner's inbox or dashboard.

Trade-offs: free tiers have submission caps; the form service is another dependency to manage; for high-volume cases, the paid tiers add up.

3. Serverless route — for projects already deployed

If the page is part of a Vercel / Netlify / Cloudflare Pages deploy, a serverless function on the same platform handles the submission. The form POSTs to /api/rsvp; the function receives the data, sends an email, optionally stores it in a database.

Cross-tool prompt:

Build this as a Next.js page with an API route at /api/rsvp that handles the form submission. The form POSTs name + email + attendance to the route; the route validates the input, sends an email via Resend / SendGrid / a simple SMTP setup, returns a JSON response. Front-end handles the submit with fetch() and shows a confirmation state on success.

Right fit: projects already on a deploy platform with auth / database / email-sending infrastructure already set up. Overkill for a single static HTML file.

Trade-offs: requires a full deploy setup, environment variables, email-provider account. Not portable as a single HTML file.

Picking the right shape

A quick decision tree:

1. Is this a personal event with under 30 expected RSVPs?

   • Yes → mailto: is fine (the visitors are probably people you know; the email-client thing isn't a dealbreaker).
   • No → next question.

2. Is the page a single static HTML file (no deploy pipeline)?

   • Yes → third-party form service embed. Formspree / Tally / Web3Forms — pick based on whether you want the submissions in email (Formspree) or in a dashboard (Tally / Typeform-style).
   • No → next question.

3. Is the page on a deploy platform with backend infrastructure already in place?

   • Yes → serverless route. The platform's API routes give you the most flexibility for validation, anti-spam, persistence.

For most one-off event microsites, AI product landings, and freelancer contact pages, the answer is option 2 — third-party form service embed.

Anti-spam considerations

A form on a publicly findable page attracts spam. Two layers worth specifying in the prompt:

• Honeypot field. Add a hidden input that legitimate users won't fill in; reject any submission that includes it (bots fill in everything). Most form services handle this automatically; for mailto: and serverless routes, add the field manually.
• CAPTCHA for higher-volume cases. Cloudflare Turnstile, hCaptcha, or Google reCAPTCHA add a friction layer that filters most bot submissions. Worth adding once the form starts getting real traffic.

For low-volume personal forms or pages distributed via private links (where the visitor list is bounded), the spam concern is minimal and the honeypot is enough.

Cross-tool nuances

Each AI builder handles the form differently:

• Claude / ChatGPT artifacts — vanilla HTML output; the prompts above apply directly. Use the Formspree-embed pattern for most cases.
• v0 — defaults to React with server actions; explicitly ask for a static HTML output with a third-party form action if you want it portable.
• Lovable — scaffolds a full project; the prompt should either accept the project-level form handling (which deploys with the project) or specify static-HTML output with third-party embed.
• Cursor — works with whatever framework you're in; the prompt depends on your project's existing form-handling pattern.

For the portable-HTML output pattern, the third-party form service is the right shape because the page stays portable while the submission flow works.

What this isn't

Static HTML + third-party form embed isn't a CRM. The submissions land in email or a dashboard; integrating with HubSpot, Salesforce, or a custom database is its own work. For most personal events, landing pages, and one-off contact forms, the integration overhead is unnecessary.

For projects that genuinely need the CRM integration, the right shape is option 3 (serverless route) plus the CRM API. The form-service shape covers everything in between.

The right framing: name the submission path in the prompt. The AI tool builds the UI well; it can't guess where the data should go. Specifying upfront is what closes the loop between "the form exists" and "the form actually works."