The end of Zapier

Zapier is a brilliant product solving a problem that shouldn't exist.

Think about what it actually does. It exists because Mailchimp and Webflow don't know each other; because your CRM and your transactional tool don't know each other; because every tool in your stack carries a private database and an API, and someone has to sit in the middle translating. Zapier is that someone. It is the glue between tools that were designed to be islands.

And glue, however good, has three inescapable properties: it is one more layer, it costs money, and it dries out and peels. This article is about why LaunchWithAgency's Flows product doesn't try to be a better glue — it makes the glue unnecessary.

The difference between glue-automation and native-automation

There are two profoundly different things both called "automation," and confusing them is the root of the problem.

Glue-automation is Zapier's kind: it connects two external systems. The trigger comes from outside (a Webflow webhook), and the action goes outside (an API call to Mailchimp). The automation has no data of its own — it just carries data from one island to another. To do that it needs credentials on both sides, it needs to know the field format on both sides, and it needs to pray neither side changes anything. It is, by definition, fragile: it depends on two APIs it doesn't control.

Native-automation operates inside the system itself. When the trigger and the action happen in the same database, the automation isn't transporting data between islands — it is reacting to one fact and producing another, in the same base. There are no third-party credentials, no field format to negotiate, no external API that can change. The automation isn't glue between products; it is one more operation over data that is already there.

Flows is native-automation. And that is only possible because of the architectural decision that holds up the entire suite: the single database.

How Flows is built

Flows is deliberately small. It has three concepts, and all three fit in one sentence: a trigger starts a run, which executes a sequence of steps in order.

The trigger can be one of three kinds. A webhook — a public URL that, when called, starts the flow; useful for an external form or a third-party system you still use. A schedule (cron) — the flow runs every minute, hour, day or week. And — the most interesting kind — an internal event: the flow fires when something happens inside the suite itself.

That last kind is the heart of the story. When someone subscribes to your newsletter, the News product doesn't call an external API or fire a webhook into the world. It records an internal event — newsletter.subscribed — in a table of the same database, flow_events. And, in the same instant, the system tries to match that event against the flows listening for it. There is no trip across the internet, no third-party queue, no webhook latency. The event and the reaction live in the same file.

The run is recorded in the flow_runs table. Every time a flow fires, a row is born there: the payload that started the run, the status (running, succeeded, failed), the start and end time, and — crucially — a step-by-step log in stepLogsJson, with the output and any error of each step. When something goes wrong, you are not guessing: the full history of every run is in the database, inspectable.

The steps are four kinds, and the choice to stop at four is a product decision, not a limitation. Send an email. Make an HTTP call. Wait a delay. Evaluate a condition (if) and branch. Those four cover the overwhelming majority of real marketing automations: "when a lead comes in, wait a day, send the welcome email, and if they opened it, send the second." There is no catalog of five hundred connectors because there are not five hundred islands to connect — there is one database, and the steps operate over it.

What disappears when the glue disappears

The practical consequence of swapping glue-automation for native-automation is that an entire class of problems ceases to exist.

The external point of failure disappears. A Zap breaks when a third-party API changes. A flow reacting to newsletter.subscribed cannot break that way — there is no third-party API involved. The event is a row in a table; the flow is a query against that table. For that to break, the database would have to break — and at that point you have bigger problems than an automation.

Transport latency disappears. Glue-automation has to wait: the webhook travels, Zapier's queue processes it, the API call returns. Native-automation reacts in the same process that generated the event.

The fragile credential disappears. There is no Mailchimp API token to expire, no Webflow permission to revoke. The flow operates on the database it already belongs to.

The separate invoice disappears. Automation isn't a fifth vendor charging per task executed. It is a capability of the suite you already have.

> Zapier charges per task because each task is an expensive crossing between two worlds. When there are not two worlds, there is no crossing — and nothing to charge for it.

When you'll still want a webhook

Honesty: the Flows webhook trigger exists precisely because the world isn't only LaunchWithAgency. You may still have a legitimate external system — a checkout, a support tool, an internal product — that needs to start an automation. Flows accepts that webhook gladly.

The difference is one of direction and quantity. In the fragmented stack, the webhook is the rule: every communication between products is a crossing. In Flows, the webhook is the exception — the bridge to what is still outside the suite. Inside the suite, communication crosses nothing, because there is no boundary to cross.

That is the exact meaning of "the end of Zapier." It isn't that automation stopped being necessary — it is more necessary than ever. It is that automation stopped being a glue product bought on the side and became what it should have been all along: a native property of the system where the data already lives.