Adding a Working Contact Form to a Google AI Studio App

Short answer: you do have a server — AI Studio's Build mode generates a React client and a Node server and deploys both to Cloud Run. The contact form still does nothing because a server is not the missing piece. Storage, email delivery and spam filtering are, and none of them arrive with a container.

Full disclosure: ShipMyForm is our product. The accounting below is the same whichever form backend you pick, and the last section is how to build it yourself on Cloud Run if you would rather.

Why this is different from v0, Bolt or Lovable

With most AI site builders the diagnosis is simple: they emit static files, a static file cannot receive a POST, and the submit button was never connected to anything. We wrote that up in making an AI-generated contact form work.

AI Studio is not that. Build mode produces a React client and a Node.js server, manages the files and packages, and deploys the pair to Cloud Run with one click. You have a real HTTP backend on a real URL.

Which makes the dead form more confusing, not less. The code looks right. There is a route. It returns success. Nothing arrives.

What the generated route is usually doing

Something close to this:

app.post("/api/contact", (req, res) => {
  const { name, email, message } = req.body;
  if (!email || !message) return res.status(400).json({ error: "Missing fields" });
  // ...and then what?
  res.json({ ok: true });
});

It validates. It returns { ok: true }. The browser shows your success state. And the submission is a local variable that goes out of scope.

This is not a bug in the generation — there is genuinely nothing sensible to put on the next line without infrastructure the model cannot create for you. It cannot sign you up for a mail provider, authenticate a sending domain, or provision a database.

The three things that are actually missing

Storage. Cloud Run containers are stateless and scale to zero, so anything written to disk disappears when the instance stops — which can be minutes after your last visitor. Keeping submissions means a real database: Cloud SQL, or Firestore, each a separate service to provision, connect, secure and pay for.

Email. Nodemailer does not send mail, it speaks SMTP to something that does. You need a provider, an API key, SPF and DKIM on your domain, and a plan for bounces — and if you skip the domain authentication your notifications land in spam, which is worse than not sending them because you believe it is working.

Spam filtering. A public endpoint gets found by bots within days of going live. Without a honeypot and rate limiting, the inbox you just wired up fills with junk and you stop reading it.

The mistake worth preventing

AI-generated apps blur the client/server line constantly, because the model is writing both halves in one conversation. In a React SPA, anything in the client bundle is public — not obscure, not minified away, public. A mail provider key that ends up there lets anyone send mail as you until you rotate it.

// If this is in a file under src/ that the client imports, it is published.
const RESEND_KEY = "re_xxxxxxxxxxxx";

Keep every key on the server side of the app, and check your deployed bundle once rather than assuming. This is the most common serious defect we see in AI-generated sites, and it is invisible in the preview.

The one-line version

If you want the form working rather than owned, point it at a form endpoint and delete the route:

<form action="https://shipmyform.com/f/YOUR_FORM_ID" method="POST">
  <input name="email" type="email" required />
  <textarea name="message" required />
  <button type="submit">Send</button>
</form>

Submissions are stored, spam-filtered and emailed to you. No database, no mail provider, no key in the bundle, and nothing to wake up.

If you are fetching rather than using a plain form — which AI Studio apps usually are — the same endpoint takes JSON:

await fetch("https://shipmyform.com/f/YOUR_FORM_ID", {
  method: "POST",
  headers: { "Content-Type": "application/json", Accept: "application/json" },
  body: JSON.stringify({ email, message }),
});

Note what is not in that snippet: no API key. The endpoint id is safe to publish — it only accepts submissions, which is the one thing you want strangers doing.

If you would rather build it on Cloud Run

Entirely reasonable, and you are closer than most people are. The honest list:

1. Provision Cloud SQL or Firestore and connect it from the service.
2. Add a mail provider, authenticate your sending domain with SPF and DKIM, and keep the key in the server environment.
3. Add a honeypot field and rate limiting per IP.
4. Decide what happens when the mail provider is down — retry, or lose it.
5. Set a minimum instance to avoid cold starts on the submit path, which ends Cloud Run's scale-to-zero pricing.

Step five is the one that surprises people: the moment you care about form latency, the free tier stops being free.

Next steps

• Built with something else? Make an AI-generated contact form work covers v0, Bolt, Lovable and Cursor.
• New to the idea: what a form backend actually is.
• Want the submitter to get a confirmation too? Do it without building a relay.
• Expecting bots: why your contact form gets spam.
• Start free — 250 submissions a month, no card required.