Backend-less apps are everywhere. Forms are the last server

Scan any Show HN feed this month and the same headline keeps appearing: “no database”. A self-destructing secret-sharing app ships with no database at all — Flashpaper, 25 points and 12 comments on HN in late July. A newsletter-unsubscribe tool advertises “no server and no database” (in-boxed). A golf career sim runs entirely on LocalStorage, billed as “no back end” (rainydaygc.com). A habit tracker ships with “no back end, no account” (My Daily Task).

Backend-less isn’t a fringe architecture debate anymore. It’s the default pitch.

”No database” is now a feature

Two years ago, a launch post bragged about its stack — Postgres, queues, workers. Now the brag is the absence of all of it. The builders shipping these apps aren’t avoiding databases out of ideology; they’ve realized most of what a database did for them was hold a few kilobytes of state that could live in the browser, in a file, or in someone’s inbox.

The pattern is consistent across everything that shows up:

State that’s per-user and disposable → LocalStorage.
State that’s shared and short-lived → a link with a TTL (Flashpaper’s whole model).
State that must reach the owner → an email.

That last one is where the backend-less story breaks.

AI builders absorbed the backend — except the form

The same week, the “build an app with AI” crowd is demonstrating the backend vanishing from the build process entirely. In How to Learn to Build an App Using AI in 15 minutes (23k+ views, 19 comments, out this week), the pitch is explicit: “You do not need to manage hosting or authentication systems all manually, because the builder handles all of that automatically behind the scenes.” From a single prompt, the tool generates the UI, the data layer, auth, and hosting.

Watch what gets generated and what doesn’t. The AI builder happily spins up a data store, but when the generated site needs to receive something — a contact form, a waitlist, an order — the agent hits a wall. There’s no “generate a receiving endpoint” step. The form is the one piece of an AI-generated site that still implies a server, a database, and a deliverability problem.

The form is where backend-less dies

Every workaround has a cost:

mailto: actions — works, but opens the visitor’s mail client and hands your address to scrapers.
LocalStorage-only forms — the submission lives on the visitor’s machine. You never see it.
Embedded survey widgets — a different design language bolted onto your site, and a leaky way to receive leads.
Rolling your own endpoint — you’ve just recreated the server you were trying to avoid: a runtime, a store, an email provider, spam filtering.

That’s the gap the last 30 days of builder chatter keeps circling. The frontend got free. The receiving end didn’t.

The pattern that closes the gap

Keep the backend-less frontend. Give the agent one endpoint that is the backend, with no database to provision:

AI agent generates the site
  → frontend POSTs submissions to one endpoint
  → endpoint validates, stores, and emails the owner
  → no server to run, no database to provision

That’s the whole loop. Builders are converging on it for the same reason they converged on static hosting: the infrastructure is solved, so they shouldn’t have to think about it. The form gets the same treatment — a form backend that receives, validates, stores, and delivers submissions to an inbox, with nothing to operate.

For AI-generated sites specifically, the win is that the agent can be pointed at the pattern once and reuse it forever. One endpoint shape, one POST, submissions in your inbox. That’s the difference between a site that looks production-ready and one that actually captures the leads it was built to capture. See the agent recipes for the exact flow.

The backend-less web is real. The forms on it just need a backend that isn’t a server.

Keep the frontend. Skip the database. Ship the form.

Start free at /start — no database required.