Where do your contact form submissions actually go?

When someone fills out the contact form on your site, what actually happens to that data? It's a question most people answer with “uhh, my email I think?” and never investigate further. But the answer matters, both for compliance reasons (yes, even for a small site) and for not losing leads.

The four common destinations

Almost every form on the modern web ends up in one (or more) of these four places:

1. An inbox. Email-only, no storage.
2. A spreadsheet. Google Sheets, Airtable, Notion DB.
3. A SaaS dashboard. Form services, CRMs, helpdesk tools.
4. A database you own. A row in your own Postgres / MySQL / SQLite.

Each has a hidden cost. Let's walk through them.

1. Inbox-only

The default for tiny sites. Every submission becomes an email; you read it, maybe reply, then archive it. Cheap, immediate, no setup.

The hidden cost: there is no “list of submissions”. There's a search of your inbox. When the form is busy you'll lose track of which ones you handled. When the form is quiet you'll miss the one that landed in spam. And you have no audit trail when GDPR comes asking what data you hold on someone.

2. Spreadsheet

The next step up. Submissions append rows to a Google Sheet via Zapier or a webhook. You can scroll, filter, copy-paste into a CRM. It's genuinely useful at small scale.

The hidden cost: spreadsheets are great at being spreadsheets and bad at being databases. Sharing access means giving full read/write to everyone. There's no concept of “handled vs unhandled”. Schema changes break formulas. And once you cross a few thousand rows, performance drops off a cliff.

3. SaaS dashboard

You sign up for a form backend (or a CRM) and submissions land in their dashboard. You log in, browse, search, export. This is what most teams settle on once they realise the spreadsheet has stopped scaling.

The hidden cost: retention windows. Many form services delete submissions after 30 or 90 days on the free plan. Make sure you understand the retention policy before you assume your form is also your archive.

4. A database you own

The most powerful, most expensive option. You write a route handler that accepts the POST, validates it, persists it, and triggers any notifications. Total control, total maintenance burden.

The hidden cost: not the database. The database is fine. The cost is everything around it: CSRF, rate limiting, spam filtering, email deliverability, dashboard UI for your team, GDPR access/deletion endpoints, retention scripts. None of these problems are hard. They're just there, and you're now responsible for solving each one.

How to pick

Three questions, in this order:

1. How long do you need to keep submissions? If “forever”, free-tier SaaS is out unless you also export elsewhere. If “until I've replied”, email-only might genuinely be enough.
2. How many people need to see them? Inbox-only stops being viable the moment you're not the only one handling them.
3. What do you do with them? If the answer is “reply once and forget”, a dashboard is plenty. If it's “feed them to a sales pipeline”, you want webhooks and a CRM, not a contact form storage layer.

The pragmatic hybrid most people land on

A form backend service is the storage layer. It's also the spam filter, the email sender, and the dashboard. Then a webhook fans submissions out to wherever else they need to go: Slack for announcements, a CRM for the ones that need follow-up, an export job for long-term archival.

You stop owning the boring parts (storage, spam, deliverability) and start writing the only piece that's actually unique to your business: the routing logic. See the post on webhook destinations for what that fan-out usually looks like.