Building with Make

1 · The visual middle ground essential

You've probably hit this wall. You built a Zap to handle incoming orders — trigger, filter, send an email — and it was gorgeous, five minutes of clicking and done. Then the requirement grew: "and for each line item, categorize it, and if it's perishable route it differently, and don't fall over when the shipping API times out." Suddenly Zapier's neat one-step-after-another chain has no place to put a loop, no branch, no retry. Your only escape hatches are "code step" (so now you're programming anyway) or a wall of duplicated Zaps. That gap — too much logic for Zapier, not enough appetite to hand-roll everything in n8n or raw code — is the exact hole Make fills.

Think of the three tools as kitchen appliances. Zapier is a toaster: one job, no dial, brilliant at it. Raw code (or a self-hosted n8n) is a full professional range — infinite control, but you'd better know how to cook. Make is the countertop multi-cooker: real dials for sauté, pressure, and slow-cook, but every setting is a knob you turn, not a recipe you write. That "real logic without writing code" is the whole pitch, and it shows up on screen as a canvas rather than a list. Where Zapier draws a vertical stack of steps, Make draws circles (modules) connected by lines, and you literally watch coloured data flow along those lines when the scenario runs.

Two vocabulary words unlock the rest of this chapter, so meet them now. A module is one node on the canvas — a single action like "Google Drive: watch files" or "OpenAI: create completion." A scenario is the whole wired-together diagram Make runs on a trigger or schedule (Make's word for what Zapier calls a "Zap" and n8n calls a "workflow"). The common beginner mistake is to treat the canvas as decoration — pretty boxes hiding the same linear list underneath. It isn't. The visual layout is the logic: a fork in the lines is a real branch, a module that swallows an array and spits out many lines is a real loop. Read the picture and you've read the program.

2 · The data-flow model essential

Here is the single misunderstanding that generates 90% of "why did my Make scenario do that?" support tickets. Someone builds a scenario that fetches an order, and downstream sends a confirmation email. They test it and get seven emails for one order. Nothing looped on purpose; no button said "repeat." The scenario simply did exactly what its data told it to — and the person didn't yet have the one mental model that would have predicted it. That model is the bundle, and it is genuinely the whole game. Learn it here and the rest of Make stops being surprising.

A bundle is Make's word for one packet of data travelling along the wire — one record, one item, one "thing to process." If you know Python, a bundle is basically a dict; if you know n8n, it's an "item." The rule that governs everything is deceptively small: a module runs once for every bundle that arrives at it. Picture a conveyor belt in a factory. Each module is a worker standing at the belt. If one box (bundle) rolls past, the worker acts once. If ten boxes roll past, the worker acts ten times — not because anyone told them to loop, but because there were ten boxes. Your email module sent seven messages because seven bundles reached it, full stop.

So the question you must always be able to answer at any point on the canvas is: "how many bundles are flowing here right now?" Most modules are one-in-one-out — a bundle comes in, a (possibly enriched) bundle goes out, count unchanged. The interesting, and dangerous, modules are the ones that change the count: an iterator turns one bundle into many, an aggregator turns many back into one, a router sends bundles down different lines. The table below is your cheat-sheet of these count-changing primitives, each paired with the plain code construct it mirrors. Keep the conveyor belt in your head as you read it — every row is really a rule about how many boxes come off the belt.

3 · Intermediate — iterators & aggregators intermediate

Recall the seven-emails story — this section is its cure. The reason one order became seven emails is that somewhere a bundle carrying an array (the seven line items) hit an Iterator, which is Make's fan-out module. An iterator's one job is to take a single bundle whose contents include a list, and explode it into one bundle per element. One order with seven items goes in; seven separate bundles come out, and from that point on the belt every downstream worker acts seven times. That is not a bug — it's the feature that lets Make do array work Zapier simply can't. The bug was leaving it un-collapsed.

The partner that collapses it is the Aggregator: the fan-in module. It waits for all the bundles from an iterator, then merges them back into a single bundle — summing numbers, joining text, or building one array. The two are a matched pair, like an opening and closing bracket. In plain code the shape is instantly familiar: the iterator is your for item in items: loop header, the middle module is the loop body, and the aggregator is the reduce / sum / "".join(...) at the end that turns the many results into one. If you open a bracket you must close it; if you fan out with an iterator you must, before any once-per-order action like an email, fan back in with an aggregator.

So the mental checklist whenever you place an iterator is: where does the fan-out end? Trace the lines downstream and find the aggregator that brings the count back to one before the "act once per order" step. If there isn't one, that step will fire once per item — the classic duplicate-email surprise. The lab below is a deliberately code-free-feeling Python stand-in: it takes one order, iterates its items, "categorizes" each (the spot a real scenario would call an AI module), then aggregates the per-item results into a single summary count — the exact iterate → process → aggregate arc drawn on a Make canvas, on one screen you can run.

scenario.pydef scenario(order):
    # iterator: one order with many line items -> a bundle per item
    items = order["items"]
    # each bundle: "AI" categorizes the item
    processed = [{"name": it["name"],
                  "category": "food" if it["perishable"] else "goods"}
                 for it in items]
    # aggregator: collapse bundles back to one summary
    summary = {}
    for pi in processed:
        summary[pi["category"]] = summary.get(pi["category"], 0) + 1
    return summary

print(scenario({"items": [{"name":"milk","perishable":True},
                          {"name":"book","perishable":False},
                          {"name":"eggs","perishable":True}]}))

{'food': 2, 'goods': 1}

4 · Advanced — error handling & control advanced

Every automation works beautifully until the day an external service hiccups. A shipping API returns a 503 for four seconds, or one bundle in a thousand has a malformed address, and a naive scenario does the worst possible thing: it stops. Worse, it stops mid-batch — of your seven fanned-out items, three processed, the fourth threw, and items five through seven never ran at all. In a hand-written program you'd wrap the risky call in try/except and decide what happens next. Make gives you the same power without code, through error handlers you attach directly to the module that might fail.

The reason there are four named handlers — Resume, Rollback, Ignore, Break — is that "handle the error" isn't one decision, it's a menu, and picking wrong is its own bug. Here is what each actually does, phrased as the question it answers. Ignore: "skip this bundle and carry on" — good for a non-critical enrichment, dangerous for a payment. Resume: "substitute a fallback value and keep going" — the graceful-degradation choice. Rollback: "undo the whole run's committed changes" (only for scenarios wrapped in a transaction), the all-or-nothing choice. Break: "retry this bundle a few times on a schedule, and if it still fails, park it and move on to the remaining bundles." Break is the one that saves the seven-item batch: item four's failure no longer poisons items five through seven.

• Retry belongs on Break. A Break handler takes a retry count and interval, so a transient 503 quietly succeeds on attempt two and nobody is paged.
• Parking beats dropping. Pair Break with a "dead-letter" data store: the bundle that never succeeds is written somewhere with its error, so you can replay it later instead of losing the event forever.
• Routers are your branches. A Router splits the flow into labelled routes with filters, so after a call you can send the good bundles one way and alert on the rest — the visual equivalent of if/elif/else.

The mistake to name out loud: reaching for Ignore because it makes the red error go away. It does — by silently discarding data. The reliability question is never "how do I stop seeing errors," it's "where does a failed bundle go," and a well-built scenario always has an answer that isn't the void.

5 · Professional — operations budget professional

The bill is where the bundle model comes back to bite you in the wallet. Make doesn't charge by the scenario or by the hour — it charges by the operation, and one operation is one module executing once, on one bundle. Every worker touching every box on the belt is a coin dropped in the meter. That pricing is fair and predictable right up until an iterator gets involved, at which point the meter starts spinning in a way that catches teams off guard: they budgeted for "500 runs a day," ran fine in testing, and got a bill sized for something ten times bigger.

Walk through why, because the arithmetic is the lesson. Suppose your scenario has two modules before the iterator and three modules after it, and it runs 500 times a day. The two front modules see one bundle each — cheap, 2 operations. But if each run's array holds 10 items, the iterator fans out to 10 bundles, and each of the three downstream modules now runs 10 times: 30 operations, not 3. So one run costs 2 + (10 × 3) = 32 operations, not 5 — and across 500 runs a month that gap is the difference between a comfortable plan and an overage. The dominant term is always the module count after the fan-out, multiplied by the fan-out width. Everything before the iterator is rounding error.

That single insight dictates the whole optimization playbook, and it's the opposite of how beginners tune. They try to shave the cheap front of the scenario; the money is at the wide back. So: filter early — drop bundles you don't need before the iterator, so the multiplier acts on fewer items. Aggregate before expensive modules — collapse back to one bundle before an AI call or an HTTP write, so that costly step runs once, not per-item. And batch instead of loop where you can — one AI call that categorizes all ten items in a single prompt is one operation and one API charge, versus ten of each inside the fan-out. Watch the operations log the way you'd watch a cloud bill: it's the honest record of how many boxes actually rolled down the belt.

6 · Tech-lead — placing Make in the toolbox tech-lead

The failure mode of a technical lead here isn't picking the wrong tool — it's picking one tool for the whole org. Someone decrees "we're a Zapier shop" or "everything goes in n8n," and six months later half the automations are fighting their platform: the Zapier ones are grotesque towers of duplicated steps faking a loop, or the n8n ones are self-hosted overkill for a two-step email. The tool is not an identity. It's a per-automation decision, and the skill a lead brings is reading a requirement and knowing which rung of the ladder it lands on before anyone starts clicking.

The reason it's a genuine ladder — Zapier → Make → n8n → code — is that each rung buys you more control at the price of more effort, and you never want to pay for control you won't use. Zapier is the top of the ladder for simplicity: unmatched connector breadth and a linear stack of steps, perfect when the flow is "when X, do Y, then Z" with no loop. Make is the rung you climb to the moment the words "for each" or "and if" appear — its iterators, aggregators, and routers are exactly the array-and-branch logic Zapier can't express, still without code. n8n is next when you need to self-host for data-residency reasons, want per-run pricing at high volume, or need to drop into real code nodes. And raw code is the bottom rung you reach for when the thing genuinely needs unit tests, version control, code review, and the kind of scale where a visual canvas becomes the bottleneck.

So the reflex to build is diagnostic, not dogmatic. Ask of each automation: does it loop over arrays? (→ Make, not Zapier.) Must it run on our own servers? (→ n8n.) Is connector breadth on a simple flow the only thing that matters? (→ Zapier.) Does it need the engineering rigor of a real codebase? (→ code.) And the harder, quieter judgment: knowing when a scenario has outgrown its rung — when a Make canvas has sprawled into forty modules that nobody can debug and it's time to graduate it to code. Picking the lowest rung that meets today's need, while planning the jump for the day the need grows, is the entire craft of this section.

[ Google Drive: Watch Files ] --bundle--> [ OCR module ] --bundle--> [ Airtable: Create Record ]
   emits 1 bundle per new file        adds bundle.text            writes text to a row

Airtable "Create Record" field mappings:
  Name    = {{ upper(1.name) }}
  Created = {{ formatDate(now; "YYYY-MM-DD") }}
  Status  = {{ if(2.confidence > 0.8; "auto"; "review") }}
  Source  = {{ 1.fileName }}

def status(confidence):
    return "auto" if confidence > 0.8 else "review"
print(status(0.9), status(0.5))   # auto review

[ Webhook: order ]
      |  order.items = [ {..}, {..}, {..} ]   (one bundle, an array field)
[ Iterator: order.items ]      --> emits N bundles, one per line item
[ Set/HTTP: price each item ]  --> each bundle now has .lineTotal
[ Array Aggregator (Numeric: SUM of lineTotal) ] --> back to ONE bundle: {total}
[ Airtable: write total ]

def iterate_price_aggregate(items, price):
    per = [{"sku": i["sku"], "lineTotal": i["qty"] * price[i["sku"]]} for i in items]
    total = sum(p["lineTotal"] for p in per)          # the Aggregator step
    return per, total

items = [{"sku":"A","qty":2}, {"sku":"B","qty":1}]
per, total = iterate_price_aggregate(items, {"A":10, "B":25})
print(per); print("total =", total)   # total = 45

[ HTTP: call API ]
   error handler:  Break (retries: 3, interval: 60s)  -- retry, then park the bundle
      on final failure --> [ Data store: dead-letter (bundle + error) ]

Router (branch after success):
   Route 1  filter: {{status = 200}}   --> [ process ]
   Route 2  fallback                   --> [ Slack: alert ]

def call_with_retry(call, tries=3, base_s=60):
    for attempt in range(1, tries + 1):
        ok = call(attempt)
        if ok:
            return f"success on attempt {attempt}"
        wait = base_s * (2 ** (attempt - 1))   # exponential backoff
        # (Make waits `interval`; shown here as the schedule)
    return "dead-letter after retries"

print(call_with_retry(lambda a: a == 2))   # success on attempt 2
print(call_with_retry(lambda a: False))     # dead-letter after retries

def monthly_ops(runs_per_day, modules_before_iter, items_per_run,
                modules_after_iter, days=30):
    # before the iterator: 1 bundle; after: items_per_run bundles
    per_run = modules_before_iter + items_per_run * modules_after_iter
    return per_run * runs_per_day * days

ops = monthly_ops(runs_per_day=500, modules_before_iter=2,
                  items_per_run=10, modules_after_iter=3)
print(f"~{ops:,} operations/month")   # iterator multiplies the after-modules by 10

def pick_tool(needs_loops, self_host_required, connector_breadth_critical,
             high_volume):
    if self_host_required:
        return "n8n (self-hostable, per-run not per-task, code nodes)"
    if needs_loops or connector_breadth_critical is False:
        return "Make (iterators/aggregators, visual data-flow)"
    if connector_breadth_critical and not needs_loops:
        return "Zapier (widest connector catalog, simplest linear Zaps)"
    return "prototype in whichever the team knows"

print(pick_tool(True, False, False, False))    # Make (loops)
print(pick_tool(False, True, False, True))      # n8n (self-host + volume)
print(pick_tool(False, False, True, False))     # Zapier (connectors)

Knowledge check check yourself