How to Handle HTML Form Submissions: 3 Simple Approaches (Backend, Provider, or Builder)

You already have a static website.

The landing page is perfect. You've spent way too many hours tweaking the copy, polishing the UI, and getting the call to action just right.

Then it hits you: people need a way to actually talk to you. A contact form, a feedback box, a "book a demo" thing — something. Doesn't matter how simple or fancy, you need a way to collect input from your visitors.

In other words, you need a working HTML form.

Easy enough — the <form> tag itself takes two minutes. The real question is: what happens when someone hits submit?

You've got three options here, roughly in order from "most control, most work" to "zero work, zero control." Let's go through them.

Option 1: Build your own backend

If you want to fully own the forms pipeline, you're looking at spinning up a backend — Express.js, Laravel, Ruby on Rails, whatever you're comfortable with. That means renting or buying a server to actually run the thing.

Then you need somewhere to put the submissions. A database. File-based if you're keeping it lightweight, a proper server-based one if you're not — either way, that's another piece of infrastructure to set up, host, and keep alive.

And that's before you've thought about validation or spam protection.

Sure, technically optional. But give it two weeks of bot submissions filling up your inbox with crypto ads and you'll be adding a honeypot field real fast.

At this point you might be thinking:

Isn't this all way easier now, with LLMs doing the heavy lifting?

Fair point — it is. Writing the actual code for a forms endpoint, validation rules, even basic spam filtering, is something an LLM can knock out in minutes instead of hours.

But that doesn't remove the part where you still need a server running somewhere, a database sitting behind it, and someone (you) responsible for both staying online. Faster code doesn't mean free infrastructure.

You can hand the hosting side to a managed provider, sure. That just moves the cost from "your time" to "your monthly bill."

Why you'd still want to do this

None of this is to say owning your backend is a bad move — for the right use case, it's the only real option.

You get complete control: custom validation logic, sanitizing input exactly how you want, wiring submissions straight into your own database or internal tools without going through anyone else's API. If your form needs to trigger something specific — kick off a workflow, write to three different systems, run business logic that's genuinely yours — this is where that lives.

It's also the only path if you're dealing with sensitive data and have strict requirements about where it's stored and who touches it.

But if what you actually want is: collect submissions, get pinged when one comes in, maybe export a CSV occasionally — building and maintaining a whole backend for that is like buying a delivery van to pick up your groceries. It'll work. It's a lot of van for the job.

Option 2: Use a form backend provider

This is the middle ground, and honestly it's where most people should land.

You keep the frontend — your form's HTML, your styling, your UI stays exactly as you built it. You just stop being responsible for what happens after submit. A form backend provider takes the server, the database, the validation, the spam filtering — everything we just complained about above — and handles it behind a single URL.

You point your form at that URL. Submissions land there instead of nowhere. That's genuinely most of it.

This is where Basilform comes in

Basilform is one option in this space (not the only one — there are several solid alternatives out there, some with more moving parts than others).

What Basilform is built around is simplicity. Not "simple" as a marketing word — actually just not making you configure things you don't care about. No dashboard full of settings you'll never touch, no pricing tiers gated behind features you don't need.

Setting it up looks like this:

1. Create a form instance — give it a name.
2. Optionally, add an email address to get notified on new submissions.
3. Copy the unique URL it gives you.
4. Drop that URL into your form's action attribute.

That's the whole setup. No server to provision, no database schema to design, no spam middleware to configure — it's already handled on the other end. You go back to working on the parts of your site you actually care about.

Option 3: Skip the HTML form entirely

If you don't even need to own the form's UI — you're fine with someone else's look and feel — you can go with a full form-building tool instead. Google Forms, Tally, Typeform, that family of products.

These are genuinely good tools, and for a lot of use cases (internal surveys, quick one-off forms, anything where the form itself doesn't need to match your brand) they're the right call. No argument there.

The tradeoff is you're now embedding or linking out to someone else's UI, which means someone else's styling, someone else's constraints, and usually someone else's logo somewhere unless you're on a paid plan.

If you want your form to actually look like your site — same fonts, same colors, same feel as the rest of your landing page — while still not touching a backend, that's the gap a service like Basilform is built to fill: your UI, their infrastructure.

So which one do you actually need?

• Building custom, business-critical, or compliance-heavy? Own the backend.
• Want your form's look kept, but don't want to touch servers? Form backend provider.
• Don't care what the form looks like, just want answers fast? Full form builder.

Most contact forms and feedback boxes fall into that middle bucket. You already did the hard part designing the page — no reason to go build a database just to catch a "hi, interested in your product" email.