Make gets dismissed by developers as the toy version of n8n. That is a mistake dressed up as taste. If the person maintaining your pipeline is an ops hire, a virtual assistant or a founder who last wrote code in 2014, a visual canvas with typed mapping and a built-in data store is not a limitation — it is the difference between a system that gets edited and one that gets abandoned the week you go on holiday. The question is never which tool is more powerful. It is who is going to open it on a Tuesday.
Pick Make when the bottleneck is people, not throughput
Make prices per operation: every module that runs on every bundle is a line item. That single fact should shape your whole design. On a self-hosted runner an extra HTTP call costs approximately nothing, so people get sloppy and enrich everything. In Make you cannot afford to, which turns out to be healthy for prospecting. It forces you to disqualify before you enrich, which is the correct order anyway and the one most teams get backwards.
The other reason to choose it: data stores, the iterator and aggregator pair, and error handler routes are all first-class citizens rather than patterns you assemble yourself. Execution history is readable by a non-technical operator. Scheduling is two clicks. For a pipeline that needs to be understood by someone other than its author, that is worth more than raw flexibility.
Scenario one: the daily harvest
One scheduler, set to run once a day at a quiet hour. First module: an HTTP request against /v1/stores/search with your API key in a header and the response parsed as JSON. Keep the filter parameters in a single Set Variables module at the top so the person editing them next month does not have to hunt through mapping panels. Platform, country, product count range, traffic band — that is usually the entire filter.
Then apply the count-first pattern. Ask for the total before you ask for rows, and put a filter on the connection: if the total is below your floor or above your ceiling, divert to a branch that messages you and stops. One operation spent, hundreds saved. The failure mode this prevents is subtle and expensive — a filter that silently matches almost nothing because a country code changed, running happily every night while producing an empty pipeline.
Pagination in Make is a repeater feeding offsets into the HTTP module, followed by an iterator that breaks the returned array into individual bundles. Give the repeater a fixed maximum. Recursive scenarios that call themselves through a webhook are elegant and will eventually run away from you at two in the morning; a capped repeater will not. Boring wins here, exactly as it does everywhere else in operations.
The data store is what stops you emailing people twice
Every no-code pipeline hits the same wall in week two: duplicates. Make ships built-in data stores — key-value tables with a fixed structure — and you should create one keyed on domain, with columns for status, score, first-seen date and last-contacted date. After the iterator, a Get a record module looks up the domain and a filter allows through only bundles where the record is empty or the last-contacted date is older than your cooling-off window.
That lookup costs one operation per store, which sounds expensive until you price the alternative: a merchant receiving your third identical opening line in six weeks, and a domain reputation you spend the next quarter repairing. Treat the data store as your source of truth and mirror it out to a spreadsheet for humans to read, not the other way round. Spreadsheets are for looking at; data stores are for deciding with.
The second use of the store is state. Keep a small record holding the last page fetched and the date of the last successful run. That is how a daily scenario picks up where it left off without any memory of its own, and how you recover cleanly after a day when the scenario was disabled. State in a store, never state in the canvas.
Scenario two: enrichment behind a router
Do not enrich inside the harvest. A second scenario, scheduled an hour later, selects rows in the harvested state and fans them through a router. Each route pulls the deeper calls it needs — /v1/stores/:domain for the full record, the catalog endpoint for products, the trend endpoint for history — and an aggregator collapses the results back into a single bundle per store so you write once instead of four times.
Route by platform, because the pitch differs. With 58,549 WooCommerce stores and 50,002 Shopify stores in the database, plus 16,501 on PrestaShop and 15,477 on JouwWeb, you are not addressing one market — you are addressing several that happen to sell things online. A WooCommerce route can lean on the detected app and payment fields, since plugin sprawl is a real and diagnosable problem. A Shopify route leans on catalog size and theme. A third route catches everything else and gets the generic treatment.
Put the cheap disqualifiers on the filters between the router and the enrichment modules, not after them. No contact email, no enrichment. Product count under your threshold, no enrichment. Traffic below the floor, no enrichment. Each filter you move one module earlier removes every downstream operation for that bundle, and those savings compound across a few thousand rows a night.
Scenario three: the signal watcher
The trend endpoint carries roughly 170 monthly buckets per store, and traffic data exists on 118,324 of them. Rather than re-enriching your whole list, run a weekly scenario over the stores you already know that pulls only the trend and compares it to the last value you stored. Route the deltas. This is the cheapest scenario in the stack and it produces the best opening lines you will ever send.
Three signals are worth an alert. A sustained decline — three consecutive months down — is a problem the merchant is already aware of and has probably not solved. A step change upward means budget and urgency, which is a different conversation entirely. And a first appearance of AI-visibility mentions, tracked across 118,363 stores, tells you a brand has started showing up in AI answers, which most merchants have not yet thought about at all.
One honesty constraint, because it matters for what you write next: this is organic search and AI-visibility data, not advertising data. Nobody in this stack can tell you what a store spends on ads or which creatives it runs, and anyone claiming otherwise is selling you a guess with a confident interface. What you can say truthfully is what a store’s organic curve did and when it changed. That is plenty, and it is verifiable, which the guess is not.
Error handling: pick the right one of the four
Make gives you explicit directives — resume, rollback, ignore, break, commit — and the discipline is attaching the right one to the right module rather than the same one everywhere. For an enrichment HTTP call, ignore with a logging branch is usually right: one dead domain should not stop the batch. For a write into your data store, rollback, because a half-written row is worse than no row. For a batch that genuinely must not be lost, break with incomplete executions stored, so you can fix the cause and resume the exact bundles that failed.
Then set the maximum number of consecutive errors, and only disable the auto-disable behaviour if you actually have monitoring. A scenario that silently switched itself off eleven days ago is the single most expensive bug in no-code automation, because nothing is broken, nothing is alerting, and your pipeline is simply empty.
The operations math, honestly
Rough per-lead accounting for the pipeline above: harvest amortised across the batch, one dedupe lookup, one detail call, one catalog call, one trend call, one aggregation, one write, plus whatever the drafting branch costs. Call it eight to twelve operations per lead that survives to your inbox. Multiply by your daily volume before you pick a plan, then work out how much of that you can shed by filtering earlier.
The cheapest optimisation is always a filter, never a plan upgrade. A hundred domains disqualified by a well-placed condition are a thousand operations you never spend. Teams that get this wrong tend to describe the problem as the tool being expensive; it is almost always the pipeline being indiscriminate.
Where Make stops and a human starts
Same conclusion as every other stack: the scenarios build and score the list, a person approves the send. The review queue is not overhead, it is your calibration loop. Five minutes a morning reading drafts will tell you more about whether the filter is right than a month of open-rate dashboards, because you will see the stores that should not have made it through.
And know the exit condition. The day you find yourself writing two hundred lines of JavaScript inside a custom module to reshape a payload, Make has stopped being the right tool for that step. Move that one step into a script or a workflow engine and keep the rest where your team can maintain it. Recognising that moment early is a genuine operational skill, and hardly anyone practises it.