Why many of our forms hand data to a provider instead of storing it locally

A contact form looks like a tiny feature. It is a name field, an email field, maybe a phone number, a message, and a submit button. The moment the website decides to store those submissions itself, the feature stops being tiny. Now the site owns a data store, retention rules, access control, backups, migrations, breach exposure, export behavior, and a way for staff to retrieve the records.

For many marketing sites, none of that is necessary.

The website's job is usually transport, not custody

A public website often needs to do four things well:

1. present a usable form
2. validate the input
3. protect the endpoint from obvious abuse
4. deliver the approved data to the system the business actually uses

That downstream system may be a form provider, CRM, scheduling tool, ticketing system, or another service designed to own the record. When that architecture fits the business, we prefer it over inventing a second local database.

We use both direct and server-mediated submission patterns

The exact boundary depends on the feature. On a simple contact page, a form can submit directly to a specialized form provider. On a gated-resource flow from another build, we needed more control. The client component owns the dialog state, email field, consent checkbox, submission status, and error messaging. It sends the data to a small server route on the same site.

That server route parses the JSON, normalizes the email, verifies that consent is explicitly true, rejects incomplete data, forwards only the approved fields to the form provider, and returns a controlled response. The browser does not get to declare the submission valid just because the checkbox looked checked.

Why the server route exists when we are not storing anything

This is an important distinction. Server-side code is not the same thing as a database. A route handler can act as a trust boundary without persisting records. It can verify input shape, restrict what is forwarded, hide provider details that should remain server-side, normalize values, handle errors, set a cookie, validate a webhook, or apply abuse controls.

That gives us application behavior without creating permanent storage.

Consent belongs in the data flow, not only the interface

If a feature requires explicit consent, the checkbox is not merely decorative copy beside the submit button. The submitted value should be part of the request. The server should verify it. The downstream record should preserve what the user agreed to in a form the business can later understand.

On the gated-resource implementation, the server only proceeds when the consent value is literally true. It then forwards a human-readable consent scope with the submission. That is a much stronger pattern than assuming that because the page contained a paragraph, every form record implies agreement.

We still validate on the client

Client-side validation is useful because it improves the experience. A required email field can prevent an obviously incomplete submission. A disabled button can prevent accidental double-submits. Inline error text can explain what happened. Those controls are for usability. The server or provider boundary is still responsible for deciding what it will accept.

Why this architecture is easier to transfer

A site with provider-based forms has a clean handoff. The repository contains the form implementation. The provider account contains the durable submissions. The destination can be changed without migrating an unrelated website database. If the client moves to a CRM later, the form route can forward there instead.

The public site does not have to be rebuilt around a data model it never needed.

What we give up

A provider dependency is still a dependency. The service can have an outage. Its API can change. Pricing can change. Deliverability can fail. Rate limits can matter. That is why we do not describe the architecture as "no backend" or "nothing to maintain."

The difference is that we are choosing a provider whose job is form delivery instead of quietly becoming the provider ourselves.

When local storage is the correct choice

If submissions need complex internal workflows, searchable records, multi-user permissions, custom reporting, cross-record relationships, or product-level state, a database may be justified. At that point, the form is part of an application. We design it accordingly.

The deeper reason we prefer this boundary

Software architecture is partly about deciding what not to own. A marketing website should own the parts that make the website good: rendering, validation, accessibility, performance, metadata, navigation, content, and the user's interaction. It does not automatically need to own every system that touches a lead after submission.

Keeping that boundary explicit gives the client a smaller attack surface, fewer moving parts, and a site that is easier to understand when somebody else inherits it.