Email capture for static sites without a backend

Before smplkit launched, we needed to collect email addresses from developers who wanted to hear about new products. The marketing site is fully static — no server, no database, no API. Just HTML on a CDN, which raises the obvious question: where does the form submit to?

Every pre-launch product hits this. The solutions run from pasting a third-party widget to architecting a serverless backend. We went with Formspree; here’s the landscape and the reasoning.

The options

Formspree — a hosted form backend. Point your form’s action at their URL; submissions land in their dashboard and get forwarded to your email. No JavaScript required.

Email marketing platforms (Mailchimp, ConvertKit, Buttondown) — an embeddable form that feeds a mailing list, with campaigns and analytics attached.

API Gateway + Lambda + DynamoDB — the AWS-native approach. Build the endpoint yourself. Total control, total responsibility.

Netlify Forms / Vercel functions — built-in form handling, if you’re already hosting there. We aren’t.

Google Forms embedded — technically works. Aesthetically, a tragedy.

Why Formspree

Zero infrastructure. smplkit’s backend runs on AWS — ECS, RDS, ALB, the works — but none of it is connected to the marketing site, and we wanted to keep it that way. Formspree gives us a form endpoint without building or maintaining anything: submission goes to their servers, we get an email, the dashboard stores the list for export. Setup took about five minutes.

The tempting alternative was jumping straight to Mailchimp or ConvertKit, since we’ll eventually want to send announcements to these people. But that’s a future problem. Right now the job is capturing interest, not running campaigns, and picking a full email platform before knowing what our mailing workflow looks like is how you end up migrating platforms twice. Formspree captures the data; when we’re ready for campaigns, we export the list and import it wherever we’ve chosen. Formspree is the bridge, not the destination.

Why not build it

For a team already on AWS, the API Gateway + Lambda + DynamoDB version is genuinely tempting: own the data, skip the third party, maybe half a day to build.

But half a day is half a day not spent on the product, and the email form is not the product. It’s a marketing function; it needs to work, and giving it production-API engineering rigor is a misallocation of attention at this stage. This is the recurring early-stage distinction between “could we build this ourselves?” — almost always yes — and “should we?” — usually no, not yet.

Implementation

The whole thing:

<form action="https://formspree.io/f/{your-form-id}" method="POST">
  <input type="email" name="email" required placeholder="you@company.com" />
  <button type="submit">Notify me</button>
</form>

Plus basic client-side validation and a thank-you state. No JavaScript framework, no state management, no API client. The same form component sits on the homepage and on the Coming Soon product pages, so a developer who finds Smpl Flags before it ships can leave an address and hear about it when it does.

What changes at scale

Formspree is the right tool for collecting a few hundred emails from a pre-launch product. When we need segmented lists, automated sequences, or A/B-tested signup flows, we’ll move to a real email platform — and the migration is an export, an import, and one changed action URL. No data loss, no architectural changes to the site.

Your form backend doesn’t need to be impressive. It needs to capture the email and get out of the way.