You don't need Zapier to send an automated email when someone signs up. A webhook from your form into a workflow tool — n8n, Make, or a few lines running on a server — plus an email API does the same job for a fraction of the cost, and it doesn't meter you per signup. Here's the setup, three ways, and how to pick.
Why does form-to-email automation get expensive?
Connector tools like Zapier price per task run. One signup that triggers "add to sheet, send welcome email, notify Slack" is three tasks. At a few hundred signups a month that's fine; at a few thousand it's a real line item, and you're paying a premium for glue code that runs in milliseconds. The automation itself is cheap. The convenience layer is what costs.
What you actually need (three parts)
Every version of this is the same three pieces:
- A trigger — your form sends an HTTP POST (a webhook) with the signup data when someone submits.
- A workflow — something receives that POST and decides what to do: validate, store, send.
- An email sender — a transactional email API (Resend, Postmark, SES, Loops) that delivers the actual message.
Swap the middle piece and you swap the cost model.
Option 1: n8n (self-hosted or cloud)
n8n is an open-source workflow tool — the same node-and-connection idea as Zapier, but you can run it yourself. Point your form's webhook at an n8n "Webhook" node, then chain nodes: validate the email, append a row to a database or sheet, call your email API, post to Slack. Self-hosted on a small VPS it's a fixed ~€5–10/month no matter how many signups run through it. n8n Cloud is priced by execution but far cheaper per run than the big connectors.
Best when: you want a visual builder, you'll have more than one automation, and you're OK maintaining a small server (or paying for their cloud).
Option 2: a serverless function + email API
Skip the workflow tool entirely. Your form POSTs to a serverless function (a Vercel/Netlify function, a Cloudflare Worker, an AWS Lambda). The function does the validation, writes to your database, and calls the email API directly. It's ~20 lines of code and, at these volumes, effectively free — serverless free tiers cover tens of thousands of invocations a month.
This is how we wire ViberzBros signups: the form hits a server action, the row is written, and a best-effort webhook fires to the email side without blocking the response. No connector in the path.
Best when: you (or someone on the team) can write a little code, and you want the fewest moving parts and the lowest cost.
Option 3: your ESP's native forms
Some email platforms (Loops, ConvertKit, MailerLite) host the form and the automation. The signup never leaves their system — form submit triggers their built-in sequence. Zero glue.
Best when: email is the only destination, you don't need the signup in your own database, and you're happy inside one vendor. The moment you need the data in two places, you're back to needing a webhook.
Which should you pick?
- Just need a welcome email, nothing fancy → Option 3. Don't build infrastructure for one email.
- Need signups in your database and in email, and you write code → Option 2. Cheapest, simplest, most control.
- Multiple automations, want a visual editor, don't want to think about it per-run → Option 1 (n8n).
All three cost less than a per-task connector once you're past a trickle of signups, and none of them are hard to set up in an afternoon.
What about the data — where do signups live?
Decide this first, because it drives the rest. If signups only ever need to be in your email tool, Option 3 is done. If they need to be somewhere you own — a database, a warehouse, a CRM — then something has to write them there, which means Option 1 or 2, and the email is just one more step in that same workflow. Don't let "send a welcome email" be the thing that decides where your customer list lives.