Zapier, Make and Custom Code: Choosing an Automation Layer

A client came to us last year with a Zapier bill of roughly $180 a month and a workflow that silently dropped leads every time their CRM returned a 429. Nobody noticed for eleven days. The Zap history showed the errors fine, but nobody was reading Zap history, because it’s not a place humans go.

That’s the actual question behind zapier vs make and “should we just write this ourselves”. It isn’t which tool has prettier branching. It’s where you want your failures to surface, who gets paged when they do, and how much you’re willing to pay per event for the privilege of not maintaining a runtime.

We’ve shipped all three approaches: pure no-code automation, self-hosted orchestration, and hand-rolled workers. Here’s the version with the trade-offs left in.

The pricing model is the architecture decision

Automation tools don’t charge for compute. They charge per unit of work, and the unit definition quietly dictates how you’ll design your flows.

Zapier counts a task as each successful action step. The trigger doesn’t count. A filter that stops the Zap doesn’t count. So a five-step Zap firing 1,000 times a month is roughly 4,000 tasks, and on a Professional plan you’re metering that against a couple of thousand included tasks. Developers respond predictably: they collapse steps into a single Code by Zapier block to save tasks. Now your “no code automation” contains an untested, unversioned JavaScript file that nobody can find.

Make counts an operation per module execution. Routers cost nothing. Filters cost nothing. But an iterator over a 50-item array costs you 50 operations on every downstream module, which is how a harmless-looking scenario burns 20,000 ops processing one CSV. The mitigation is the aggregator. If you’re not using aggregators in Make, you’re overpaying.

Rough working rule from our own billing: at 5,000 to 10,000 events a month with multi-step logic, Make lands somewhere near a third to a fifth of the Zapier cost. Past about 100,000 events a month, both start looking silly next to a $5 Cloudflare Workers bill, and the conversation changes.

Zapier vs Make: what each is actually good at

Forget feature matrices. These tools have different centres of gravity.

Zapier

App coverage is the moat. Thousands of integrations, and crucially the long tail: obscure accounting tools, regional payment providers, the CRM your client bought in 2019. Zapier’s linear step list is also its best UX property. A marketing manager can open a Zap and read it top to bottom like a sentence. That matters more than developers admit, because the automation you can’t hand over becomes your permanent responsibility.

Where it hurts: branching via Paths is clumsy past two levels, error handling is basically “it failed, we’ll retry and email you”, and loops are an afterthought. Task pricing punishes exactly the workflows worth automating.

Make

Make is a dataflow canvas, and it behaves like one. Routers with per-branch filters, iterators, aggregators, and an error handler route you can attach to any individual module with directives like Resume, Break and Ignore. You can inspect every bundle of every execution, which turns debugging from guesswork into reading. Make also lets you build a custom HTTP module in five minutes for any API that doesn’t have an official app, which closes most of the integration gap.

Where it hurts: the canvas becomes unreadable at around 25 modules, versioning is weak (clone the scenario and hope), and handing a complex Make scenario to a non-technical client is not a handover, it’s a hostage transfer.

The third option people skip

n8n deserves a mention because it changed our defaults. It’s self-hostable, node-based, and you pay for a server rather than per execution. For a client running 400,000 internal events a month, that’s the difference between a $30 VPS and a four-figure SaaS invoice. The cost is real: you now own upgrades, a Postgres instance, and the on-call rota. Don’t self-host orchestration unless someone is genuinely responsible for it.

Where no-code automation reliably breaks

Four failure modes, all of which we’ve cleaned up on client sites.

1. Silent partial failure. Step 3 of 6 fails. Steps 1 and 2 already wrote data. There’s no transaction, no rollback, no compensating action. You now have a half-created customer. Make’s error routes let you handle this deliberately. Zapier mostly does not.
2. Duplicate delivery. Webhook senders retry. If your automation has no idempotency key, a Stripe retry becomes two invoices. Almost nobody adds a dedupe step, because in a visual builder it’s ugly and costs operations.
3. Nobody watches the dashboard. Both platforms notify by email, which routes straight to a folder nobody opens. Wire failures into Slack or PagerDuty on day one, or accept that you will discover breakage from a customer.
4. Logic drift. Business rules in a visual canvas can’t be code reviewed, diffed, or tested. When the rule matters (pricing, tax, eligibility, anything with legal consequence), it belongs in a repo.

If your workflow touches personal data, there’s a fifth: retention. Zapier and Make both keep execution logs containing the full payload, which means copies of form submissions sitting in an third-party system for however long your plan retains them. That’s a genuine consideration for GDPR and contact forms, and it’s the sort of thing an auditor finds immediately.

Own the edge, rent the middle

The pattern that keeps working: put a thin piece of code in front of your automation tool. It verifies signatures, deduplicates, responds fast, and forwards a clean normalised payload to Make or Zapier. Everything fragile is yours. Everything that changes weekly stays no-code.

Here’s a Cloudflare Worker doing exactly that. Sixty lines, and it removes three of the four failure modes above.

export default {
  async fetch(request, env) {
    if (request.method !== 'POST') return new Response('Method not allowed', { status: 405 });

    const raw = await request.text();
    const signature = request.headers.get('x-signature') || '';

    if (!(await verify(raw, signature, env.SIGNING_SECRET))) {
      return new Response('Bad signature', { status: 401 });
    }

    const payload = JSON.parse(raw);
    // Prefer the sender's event id. Fall back to a stable hash of the body.
    const key = evt:${payload.id ?? await sha256(raw)};

    // Dedupe window of 24h. KV writes are eventually consistent, so this is
    // best-effort: use it to stop retries, not to enforce financial uniqueness.
    if (await env.SEEN.get(key)) return new Response('Duplicate', { status: 200 });
    await env.SEEN.put(key, '1', { expirationTtl: 86400 });

    await env.WORK.send({
      type: payload.event_type,
      email: payload.data?.email?.toLowerCase().trim(),
      amount_cents: Math.round((payload.data?.amount ?? 0) * 100),
      received_at: new Date().toISOString()
    });

    return new Response('OK', { status: 202 }); // ack immediately, work happens later
  },

  async queue(batch, env) {
    for (const msg of batch.messages) {
      const res = await fetch(env.MAKEWEBHOOKURL, {
        method: 'POST',
        headers: { 'content-type': 'application/json' },
        body: JSON.stringify(msg.body)
      });
      // Non-2xx: retry with backoff instead of losing the event.
      if (!res.ok) { msg.retry(); continue; }
      msg.ack();
    }
  }
};

async function verify(body, hex, secret) {
  const key = await crypto.subtle.importKey(
    'raw', new TextEncoder().encode(secret),
    { name: 'HMAC', hash: 'SHA-256' }, false, ['sign']
  );
  const mac = await crypto.subtle.sign('HMAC', key, new TextEncoder().encode(body));
  const expected = [...new Uint8Array(mac)].map(b => b.toString(16).padStart(2, '0')).join('');
  if (expected.length !== hex.length) return false;
  // Constant-time-ish compare: never bail early on first mismatch.
  let diff = 0;
  for (let i = 0; i < expected.length; i++) diff |= expected.charCodeAt(i) ^ hex.charCodeAt(i);
  return diff === 0;
}

async function sha256(s) {
  const d = await crypto.subtle.digest('SHA-256', new TextEncoder().encode(s));
  return [...new Uint8Array(d)].map(b => b.toString(16).padStart(2, '0')).join('');
}

Note the 202 before any downstream call. Acking first and working later is the whole game, and we’ve written about why at length in queues for webhook processing. If the difference between a webhook and an API call is still fuzzy, this piece covers it.

For the front end of this chain on a static site, you often don’t need any of it. A form posting to WebForms gets you email, Slack and webhook delivery without a backend, and the webhook output is what you feed into Make. That’s usually the right starting point for a brochure site: no server, no cron, no secrets to rotate.

A decision procedure that takes ten minutes

Answer these in order and stop at the first yes.

• Is the logic load-bearing? Money, access control, legal obligations, anything a regulator might ask about. Write code. Test it.
• Do you need the same event processed exactly once? Write the dedupe layer yourself. Visual tools can approximate it, not guarantee it.
• Is volume above roughly 100k events a month? Per-task pricing stops making sense. Consider n8n on a VPS, Cloudflare Workers plus Queues, or a durable execution engine like Inngest or Temporal if you have genuine long-running orchestration.
• Does a non-developer need to own this? Zapier. Pay the premium for legibility and the app catalogue.
• Everything else? Make. Better price per unit of work, real error handling, and an HTTP module for anything missing.

One more test, less technical: how often will this change? Rules that change monthly belong somewhere a human can edit without a deploy. Rules that haven’t changed in two years belong in git. Most teams get this backwards, putting their stable logic in Zapier while their volatile logic sits in a Lambda nobody wants to touch.

Operating an automation layer you can trust

Whatever you pick, these five things separate a workflow that runs for two years from one that fails in week three.

Route every failure to a channel humans read. A Slack webhook on the error path, not email. Include the payload id and a direct link to the execution.

Name scenarios and Zaps like code paths: stripe.invoice.paid -> hubspot deal, not New Zap (3). Version by exporting JSON into the repo, even if you never re-import it, because the diff tells you who changed what.

Cap your loops. Every iterator gets a maximum, every paginated fetch gets a page limit. A runaway scenario can eat a month of operations in twenty minutes, and it always happens on a Friday.

Test with real bad data: empty strings, nulls where you expected objects, an email with a plus sign in it, a 200-character company name. No-code builders infer types from the first successful run, so they’re brittle in exactly the ways your production traffic is creative.

Finally, keep secrets out of Code steps. Use the platform’s connection store or environment variables, and rotate them when contractors leave. We’ve inherited more than one Zap with a live API key pasted into a JavaScript block.