How Do You Handle Form Submissions Without a Backend?

How Do You Handle Form Submissions Without a Backend?

You do not need a server, but something has to receive the POST, validate it, block the bots and put the data somewhere. That job now fits in one serverless function or one hosted form service. The choice between them is mostly about who you want maintaining it in two years.

Most of the marketing sites we build are static. They are prerendered at build time and served as files. Then a contact form arrives in the brief and someone asks where the data goes.

This is the walkthrough we give. What the form actually needs, the three ways to provide it, and the decisions that bite later.

What Does a Form Actually Need Behind It?

Five things, and only five. Somewhere to receive the request. Validation of what arrived. Spam filtering. Delivery to wherever the data belongs. And a record you can check when someone says they never got a reply.

Notice what is not on the list. You do not need a database for most marketing forms, because the data is passing through to a CRM or an inbox. You do not need sessions, accounts or an admin panel.

That is why a static site plus one small piece of server code covers almost every B2B marketing form we are asked to build.

What Are the Three Realistic Options?

A hosted form service, your platform's built-in form handling, or a single serverless function you own. Each of them is a reasonable answer, and the right one depends on who will change it next.

A hosted service takes the POST at their endpoint and forwards it on. Your platform's built-in handling, such as the forms built into Webflow, keeps everything in one place. A serverless function is your own code running on demand.

We would say the ranking for most B2B marketing sites is built-in first, hosted service second, custom function when the first two genuinely cannot do the job. The order is about maintenance, not capability.

If you are on Webflow, start by reading what the native option already gives you, which we covered in the guide to Webflow forms before you build anything custom.

When Does a Custom Function Become Worth It?

When you need logic the platform will not give you. Routing a submission to a different sales rep by company size. Enriching the record before it reaches the CRM. Calling two systems and handling one failing. Rejecting a submission based on a rule only you know.

Those are real reasons. Wanting the code in your repository is not, on its own, a strong enough one for a marketing site.

The test we use is whether a marketer will ever need to change the form without a developer. If yes, keep it native. Every custom endpoint turns a five minute field change into a deployment.

What Does a Serverless Function Actually Give You?

A piece of code that runs when a request arrives and costs nothing when idle. Vercel's documentation describes Vercel Functions as scaling automatically with traffic and scaling down to zero when there are no requests, with support for Node.js, Python, Go and other runtimes.

The numbers are generous for a form. Vercel documents a default maximum duration of 300 seconds on all plans, and automatic concurrency scaling up to 30,000 on Hobby and Pro. A form submission needs a fraction of a second.

Region matters more than most people expect. Vercel's docs state functions run in a single region by default, iad1 in Washington DC, and recommend running them close to your data source. If your CRM lives in Europe, that default is adding a round trip on every submission.

Where Does the 4.5 MB Limit Catch You?

On file uploads. Vercel documents a maximum payload size of 4.5 MB for the request body or the response body of a function, returning a 413 error when exceeded. A CV, a design brief or a set of photographs will pass that easily.

The fix is not a bigger function. It is to stop routing the file through your function at all. Have the browser upload directly to object storage using a short-lived signed URL that your function generates, then send only the resulting file reference through the form.

This pattern is worth learning once. It is the same shape whichever storage provider you use, and it is the difference between a careers page that works and one that silently fails for the strongest candidates.

How Do You Stop Spam Without a CAPTCHA?

Layer cheap checks before expensive ones. A honeypot field that humans never see and bots fill in. A minimum time between page load and submission. Server side validation that rejects obviously malformed input. Most automated spam fails at least one of these.

When you need more, use an invisible challenge rather than a puzzle. Cloudflare's documentation describes Turnstile as offering three widget modes: managed, which shows a checkbox only when risk warrants it, non-interactive, where visitors never need to interact, and invisible.

Accessibility is a real reason to prefer this class of tool. Cloudflare states Turnstile is WCAG 2.2 AA compliant and that it does not access user communications or form data, only security-relevant signals.

Whatever you choose, do the check on the server. A client side check is a suggestion. We go deeper on the full range of defences in how to stop form spam.

Where Should the Data Actually Go?

To the system that owns the follow-up, plus one durable copy you control. For most B2B companies that means the CRM as the destination and a simple log or spreadsheet as the backup.

The backup is the part teams skip and then regret. Integrations break quietly. A field gets renamed, an API key expires, a rate limit is hit. If the only copy of a submission was in transit, it is gone.

Email alone is not a record. It is a notification. Treat it as the thing that wakes someone up, not the thing that stores the lead.

What Should You Return to the Person Submitting?

A real confirmation, quickly, and an honest error when something fails. The worst pattern is the form that appears to succeed because the code fired and forgot, while the request to the CRM failed in the background.

Decide deliberately which failures the visitor should see. If your durable copy was written, the submission succeeded from their point of view even if the CRM call failed, and you should say so and fix the CRM behind the scenes. If nothing was stored, tell them.

Keep the confirmation on the same page rather than redirecting where you can. It is faster and it keeps your analytics simpler, which matters for the conversion tracking most teams bolt on later.

How Do You Know It Is Still Working?

Submit the form yourself on a schedule. That sounds too simple to be a real recommendation and it is the only check that tests the whole path. Everything else tests a piece of it.

Add an alert on absence, not just on errors. A form that has received zero submissions in three days when it normally gets ten is broken, and no error log will tell you that.

Log the failures somewhere a person looks. A function that catches an exception and returns a friendly message, without recording anything, converts a visible outage into an invisible one. The same principle applies across your stack, as we argued in the website security guide.

What Would We Build for a Typical B2B Site?

Native platform forms for anything a marketer maintains, a single owned function for the one or two forms with real logic, an invisible bot check on both, and every submission written to a durable store before anything else happens.

That setup is boring, cheap, and survives the person who built it leaving. Those are the three properties that matter most for infrastructure nobody is going to think about again.

If you want help deciding which of your forms needs real code behind it, or building the piece that does, we are happy to walk through it. You can find us at phoenix.studio.