Inngest vs Zapier: when workflows belong in code

The no-code workflow ceiling

Zapier and Make are brilliant for stitching APIs together when you're moving fast and the stakes are low. You can wire Stripe to Slack, or Gmail to Airtable, in ten minutes. No deployment pipeline. No infra.

But every team that scales with these tools eventually hits the same wall. A customer onboarding flow that touches five services. A data sync that runs every fifteen minutes and occasionally fails halfway through. A refund process that needs to wait for human approval, then resume exactly where it left off.

These aren't edge cases. They're table stakes for operational software. And the moment you need them, visual workflow builders start to hurt.

Where the drag-and-drop model breaks

The first problem is state. Zapier has no concept of a durable step. If your workflow fails on step eight of twelve, you don't get a replay button — you get a manual re-trigger from the top, which often means duplicate actions or orphaned records. Make has multi-step error recovery, but only if you wire it explicitly, and the UI becomes a spaghetti diagram.

The second is versioning. You can't diff a Zapier workflow. You can't branch it. You can't roll it back with confidence. Every change is live immediately, and your only audit trail is a change log that shows who clicked what, not what the logic actually does now versus an hour ago.

The third is observability. Execution logs are paginated tables of JSON blobs. There's no structured tracing, no span-level timing, no way to aggregate errors by type or see which step in which workflow is your biggest time sink. When something goes wrong in production — and it will — you're hunting through logs with Cmd+F.

The fourth is cost. Zapier's pricing scales with task volume, not complexity. A ten-step workflow costs ten times a one-step workflow, even if those steps are trivial transformations. We've seen teams hit £600/month before they realise the bill is tied to execution count, not business value.

What Inngest (or code-first workflow engines) actually give you

Inngest is a TypeScript-native workflow engine. You define steps as functions. Each step runs in its own durable execution context. If step three fails, Inngest retries it — not the whole workflow. If you deploy new code, in-flight workflows keep running on the old version until they finish.

Here's what a two-step workflow looks like:

export default inngest.createFunction(
  { id: 'process-refund' },
  { event: 'order/refund.requested' },
  async ({ event, step }) => {
    const refund = await step.run('create-refund', async () => {
      return stripe.refunds.create({ charge: event.data.chargeId });
    });
 
    await step.run('notify-customer', async () => {
      return sendEmail(event.data.email, refund.id);
    });
  }
);

Each step.run is atomic. Each one gets retried independently. The function as a whole is versioned with your application code, diffable in Git, testable in CI.

The real differentiator: durability and observability

Durability means your workflows survive process crashes, deploys, and transient failures. If your serverless function times out, Inngest picks up where it left off. If Stripe returns a 429, Inngest backs off and retries. You don't write retry logic. You don't write state machines. You write the happy path.

Observability means you see every step's inputs, outputs, and timing in a structured trace. You can filter by event type, by failure reason, by latency percentile. You can replay a failed run with one click. You can see which workflows are slow, which are expensive, which are failing more than they should.

Zapier gives you neither. Make gives you partial durability if you architect it carefully, but still no real observability.

What you trade

Inngest isn't free. The hosted tier starts at $20/month and scales with event volume. Self-hosting is possible but adds operational overhead. You're also committing to TypeScript (or Python, if you use Temporal or Hatchet instead). If your team doesn't write code, this doesn't help you.

But the trade is control. You own the workflow definition. You version it. You test it. You observe it. When it breaks, you fix it in code and deploy, rather than clicking through a UI hoping you didn't miss a toggle.

When to choose code

Use Zapier when you're prototyping, when the workflow is genuinely simple (trigger → transform → action), or when the people managing it don't write code.

Use Inngest when workflows are mission-critical, when they touch money or customer data, when they need to compose with your existing application logic, or when failure means lost revenue rather than lost convenience.

The tipping point is durability. If you need to guarantee that every event is processed exactly once, even across deploys and failures, you need a workflow engine that treats state as a first-class primitive. Everything else is a nice-to-have until it isn't.