How I Built a Newsletter Welcome Sequence in an Hour with Next Gen Zaps

Buttondown’s built-in automations sit behind a plan that is disproportionate for a 200-subscriber newsletter, so this article explains how a one-hour build with Next Gen Zaps creates a five-email welcome sequence. It covers enrolment, sending, edge cases and testing, while leaving email delivery and unsubscribe handling to Buttondown.

Zapier

Dennis Chiuten

Oct 27, 2026

Flow Statements has the same problem as every small newsletter: new subscribers arrive at random, and the first thing they receive is whatever I happen to publish next. That could be a week away, or three. Meanwhile, some of the more useful pieces I've written are buried in the archive, where nobody new is likely to find them.

The standard fix for this is a welcome sequence: a short series of emails, sent automatically over someone's first few weeks, that introduces the newsletter and walks them through a few evergreen posts. Most email platforms have this built in. Buttondown, which I use and love, is no exception. Its Automations feature is designed for exactly this; the problem is that it's not included on our current plan.

Why I didn't upgrade

I'm a firm believer in paying for high-quality tools that deliver a lot of value, and Buttondown is one of them. But the tier that includes Automations would have tripled our subscription cost, and it covers up to 5,000 subscribers. Flow Statements has around 200. That tier clearly isn't aimed at writers with an audience our size, and paying 3x for headroom we won't need for a long time just didn’t make sense.

So I built the sequence myself in Zapier, using Claude Code and Next Gen Zaps. It took about an hour.

What I built

If you missed my earlier post on Next Gen Zap Workflows, the short version: a Next Gen Zap is a TypeScript file, written and edited by a coding agent through the Zapier SDK and its CLI, then hosted and run on Zapier's servers. I now have more than 70 running (not counting the ones I’ve built for clients), all managed in one GitHub repo.

The welcome sequence has three parts:

A Zapier Table that tracks each subscriber's place in the sequence: which email they get next, when it's due, when they confirmed, and whether they're active, completed, stopped or paused.
An enrolment Zap that fires when someone confirms their subscription and adds them to the Table.
A sender Zap that runs every hour, picks up anyone who's due, and sends them their next email.

The sequence itself is five emails over about a month: a new welcome email on day 0, then four refreshed posts from the archive on days 4, 11, 18 and 25.

Buttondown still does all the sending. Zapier tells it which email to send to which subscriber, using an API endpoint that sends one email to one person. So every email carries Buttondown's unsubscribe link and respects its suppression rules, and I didn't have to build any of that.

Everything in code, including the setup

Most of the time saved came from everything around the Zaps.

Claude Code created the Zapier Table through the CLI, so I didn't have to set up eleven fields manually. Like an animal.

It then pulled the four archive issues I’d selected using Buttondown's API, refreshed the details that had gone stale (Notion Workers and their pricing have moved on since I wrote about them in May, for example), wrote a short intro for each explaining why it was turning up in a new subscriber's inbox, and created all five as new private emails in Buttondown.

That last step had a couple of traps I'd never have found on my own without a lot of trial and error. Buttondown's API refuses to send an email that's still a draft, so each one has to be created as a draft and then switched to an "imported" status, which keeps it away from the regular list while leaving it editable. Claude Code hit that while testing against the API and wrote the procedure into the README, so the next email I add follows the same steps. I barely even knew this was happening until Claude Code built the fix and told me about it afterward.

Why this would have taken forever in classic Zaps

I never tried to build a drip sequence like this in the classic Zap editor because I knew there would be a lot of edge cases you have to account for, and didn’t trust myself to catch them all unless I was prepared to spend a lot of time testing. This one handles a bunch of these:

Bots don't get enrolled. Flow Statements was hit by a wave of list-bombing signups in September. Claude Code analysed all those spam sign-ups, identified common patterns in the email addresses, and built in filters to exclude any similar ones in the future.
Unsubscribes stop the sequence. Before every send, the sender checks that the subscriber is still subscribed. If they aren't, their row is marked as stopped.
Nobody gets the same email twice. If an email goes out but the Zap fails before recording it, the next run could try to send it again. Buttondown spots that it's already been sent and blocks the duplicate, so the Zap moves on to the next email.
A late run doesn't push everyone back. Send dates are calculated from the day someone confirmed, so if the Zap is down for a day, nobody's schedule drifts. Anyone who falls behind gets their overdue emails at least two days apart, rather than one an hour.
Failures get flagged. One bad row can't hold up everyone else. If a subscriber's send fails three times in a row, their row is paused and I get a single Zapier error alert.

In the classic editor, each of these means more Paths, more Filters, Formatter steps for the date maths, and a Looping step to work through the Table. It's all doable, but it's easily a couple of days of building and clicking through test runs, one step at a time. In code, each one is a few lines, and the coding agent wrote them.

Testing a month-long sequence in minutes

Claude Code could do the testing itself, from signing up to checking that the emails arrived. It created and used a throwaway email address that forwards to my Gmail and signed up for the newsletter, just as a reader would. It could work through Zapier to use the apps' APIs, or open its browser and fill in the sign-up form.

From there, it ran through the whole sequence, jumping ahead in time so we didn't have to wait a month for all five emails. It checked what happened when something failed, whether delayed emails stayed properly spaced, and whether the sequence stopped when it was finished. I didn't have to create test subscribers or click through every (or any) step myself.

What it costs

Zapier Table reads and writes don't use tasks, so an hour where nobody is due costs nothing. Each send uses two tasks (one to check the subscriber, one to send), which works out at about a dozen tasks per subscriber over the full sequence. At our volume, that's a rounding error next to the cost of upgrading our Buttondown plan upgrade.

The result

New subscribers now get a proper introduction and four of my favourite posts, regardless of when I next publish. Anyone who's subscribed since last weekend is already on it.

If you've got a similar gap in your own stack, this approach works well beyond newsletters. Zapier Tables can keep track of where each item is in a process and what needs to happen next, while a coding agent builds the workflow, finds the edge cases, and tests how it handles them. If you'd like help working out whether it fits your setup, get in touch. It's the kind of build we deliver through our Zapier consulting.

Book a discovery call Message us on WhatsApp

AI Is Writing Faster Than We Can Read

Dennis Chiuten