The short answer
A form backend is a hosted HTTPS endpoint that receives submissions from a static website, stores them, and notifies you — replacing the server-side code a static site can't run. When choosing one, the questions that matter are: where the data is stored and who owns it, whether the endpoint survives you cancelling the service, how spam is handled, whether it works without a build step, and what happens when volume grows. RG Forms answers the ownership question differently from most: the endpoint is a Google Apps Script web app in your own Google account and submissions land in your own Google Sheet, so there is no vendor holding your data.
The definition
A form backend is a hosted endpoint that does the server half of a form submission on behalf of a site that has no server. At minimum it accepts a POST, stores the data, and tells you about it. Beyond that, providers add dashboards, integrations, autoresponders, file uploads, workflow rules and analytics.
The category exists because static hosting won. Once your site is files on a CDN, the form is the one piece that still needs something running — and nobody wants to stand up a server for a single POST route.
Eight questions worth asking
In roughly the order they’ll bite you:
Where does the data physically live? — the provider’s database, or somewhere you control? This determines what you can say to a client about their leads, and what happens in a dispute.
What happens if you stop paying — or they stop operating? — do submissions become unreachable, or is the archive already somewhere you own? Ask this before volume gets interesting.
How is spam handled? — a honeypot catches the cheap stuff. A server-side captcha check catches the rest. Client-side-only filtering catches neither.
Does it need a build step or a framework? — if the integration is a plain
fetch, it works everywhere forever. If it’s an SDK, you’ve taken on a dependency.How do notifications actually send? — through the provider’s mail infrastructure, or from your own account? This affects deliverability, the reply-to address, and daily limits.
Can one project serve several forms? — contact, newsletter, quote request. Paying per form, or juggling four endpoint URLs, gets old.
Is the data exportable in a format you’d actually use? — CSV export is table stakes. Data that’s already in a spreadsheet skips the question entirely.
What does it cost at 10× today’s volume? — most pricing is per submission per month. Model the year you succeed, not the month you launch.
How RG Forms answers those
Data lives in a Google Sheet in your Drive. If RG Forms disappeared tonight, your endpoint would keep serving requests tomorrow, because it’s an Apps Script deployment in your account with no dependency on rgforms.com.
Spam is a hidden honeypot field plus optional Cloudflare Turnstile, verified server-side inside your script before anything is written. Integration is a plain fetch — no SDK, no build step, no framework requirement. Notifications send from your own Google account, so replies come back to you and the reply-to is the visitor’s address.
One project covers as many forms as you need — each is a tab in the same Sheet behind one endpoint URL. And it’s free, because there’s no infrastructure for anyone to bill you for.
Common questions
Is a form backend the same as a form builder?
No. A form builder gives you the form itself — a hosted page or embed with a drag-and-drop editor. A form backend takes the form *you* built in your own HTML and handles what happens after Submit. If you want to design the form yourself, you want a backend.
Do I still need one if my host has built-in forms?
Not necessarily — host-native forms are convenient if you’re staying put. An independent backend is worth it when you want the data somewhere you own, or want the site to be portable between hosts without rewriting the form.
Can a form backend work without JavaScript?
Some support a plain HTML action= POST with a redirect, which works without JS. RG Forms uses fetch, which means JavaScript is required — the trade is that the visitor stays on your page instead of being bounced to a third-party thank-you screen.
More answers in the full FAQ.