In one hour, you can pick the right automation platform for your first three agents — and avoid the eighteen-month migration that follows from choosing wrong. Zapier, Make, n8n, and Lindy each win a different lane. The four-question test below tells you which lane is yours, before the procurement form lands on your desk.

Why the Platform Decision Matters More Than the Tool

Operator-builders in 2026 are spoiled for choice. Zapier has eight thousand connectors and the friendliest UX in the category. Make has visual scenarios and a 90%-cheaper per-operation cost. n8n is open-source, self-hostable, and the de facto runtime for engineering teams who refuse to be locked in. Lindy is AI-native — its primitives are agents, not zaps. Any of these can build your first three automations. None of them is a good fit for all three.

The cost of choosing wrong is not the monthly subscription. It is the rebuild. If you ship six automations on Zapier and then hit the 60,000-task threshold where Team-tier pricing becomes indefensible, every one of those automations has to be redrawn in Make or n8n. If you ship on Lindy because the demo was magical and then discover your finance team won't approve an AI-native SaaS that holds prospect data outside your tenant, every Lindy flow becomes a sunk cost. The platform choice is structural — it shapes which integrations are cheap, which patterns are idiomatic, which audit logs you can produce, and where your operational expertise compounds.

You are not choosing a tool. You are choosing the gravity well your next two years of automation will fall into. Pick the wrong well and every later decision gets harder.

The Four-Question Test

Four questions, asked in this order, will narrow the field from "every platform looks good" to "this is the platform for this workload" in under an hour. The test is workload-specific — you run it once per automation you intend to ship, not once per company. A finance reconciliation agent and a sales-routing agent may end up on different platforms, and that's fine.

Question 1: Data sovereignty — does this workload need to stay inside your perimeter?

If the answer is yes — because the data is regulated (HIPAA, PCI, GDPR-sensitive), because legal has said no third-party SaaS can hold the payload, or because the agent will be acting on customer records that your contracts say stay in-region — Zapier, Make, and Lindy are off the table for this workload. They run on their own infrastructure. They hold your data, even if briefly, in transit through their execution environment. Their SOC2 and ISO certifications cover their own controls but not the question of whether your data leaves your tenant.

n8n is the answer here, because n8n can be self-hosted. The exact same nodes you'd use on n8n Cloud Pro run on a VPS you control, in a region you choose, with logs you own. n8n has an EU-hosted Cloud tier as well if "your region, their box" is acceptable. But if "your region, your box" is the requirement, n8n is the only one of the four that supports it.

A real test: ask your CISO or legal counsel, "If we put a customer's PII through a Zapier zap that hits OpenAI, what's our data-processing posture?" If the answer is a 90-minute conversation about subprocessors and DPAs, that workload belongs on self-hosted n8n. If the answer is a shrug, you have a different governance problem, but Zapier remains an option.

Question 2: Code escape hatches — will you eventually need to drop into code?

Every non-trivial automation hits the wall where the visual builder isn't expressive enough. A regex you can't write in the UI. A loop that needs early termination. A retry policy with exponential backoff and jitter. A data transformation that's three lines of Python but seventeen no-code steps.

Each platform handles this differently:

• Zapier: Code by Zapier (JavaScript or Python in a sandboxed step). Limited to short, mostly-pure transformations. Cannot import arbitrary npm packages. Adequate for parsing and formatting; awkward for anything stateful.
• Make: No first-class code module in the same way. You can call external functions (Cloud Functions, AWS Lambda) but the in-platform "tools" module is narrower than Zapier's Code step. Make compensates with a richer expression language.
• n8n: A "Code" node that runs JavaScript or Python with reasonable library access. A "Function" node for inline logic. Because n8n is open-source, the boundary between platform and code is the loosest — you can fork, add custom nodes, contribute to core. For engineering-leaning teams, this is decisive.
• Lindy: AI-native primitives instead of code. You describe what you want in natural language and Lindy's agent assembles the steps. There is a "code" tool for power users, but the dominant pattern is "tell the agent." This is wonderful for AI-shaped problems and frustrating for deterministic ones.

If your team has one engineer and three operators, Zapier or n8n. If your team has zero engineers, Zapier or Lindy. If your team has three engineers and one operator, n8n. The platform should match the median skill level of the people who will maintain the automation, not the most senior.

Question 3: AI-native primitives — is the agent the workflow, or a step in the workflow?

This is the question most operator-builders get wrong. They look at a workload and ask "can I add an OpenAI node?" The answer is always yes — every platform now has at least one LLM connector. But that's not the question.

The real question is: in this workload, is the agent the system (driving decisions, calling tools, looping until done), or is the agent a step (taking a payload in, returning text out, with the deterministic workflow handling everything else)?

If the agent is a step — "summarize this email," "extract these fields," "score this lead 0-100" — any platform works. Zapier's AI by Zapier, Make's OpenAI module, n8n's LLM nodes, and Lindy's natural-language steps all handle the "agent-as-step" pattern equivalently. Choose on data sovereignty (Q1) and code escape (Q2).

If the agent is the system — it loops, it chooses which tool to call next, it decides when it's done, it manages its own state — Lindy is dramatically better. Lindy was built around the agent loop. Memory, tool choice, and iteration are first-class. The other three platforms can be coerced into agent-loop patterns (n8n has the most expressive support; Zapier's "Agents" beta is improving), but they are workflow engines pretending to be agent engines.

Workflow platforms with LLM nodes are good at "AI step inside a deterministic flow." Agent platforms like Lindy are good at "deterministic steps inside an AI flow." Know which shape your problem has before you pick the platform.

Question 4: Team skill — who's going to maintain this in eighteen months?

The platform that ships fastest is rarely the platform that survives longest. Zapier zaps written by an enthusiastic ops manager in 2024 are still running in 2026, and her successor can read them. n8n workflows written by an engineer in 2024 are still running in 2026, and her successor (also an engineer) can read them. Make scenarios written by either, with care, are also readable. Lindy automations from 2024 are partially-still-running because Lindy has shipped three breaking schema changes since — that's the cost of being on a fast-moving AI-native platform.

Ask: who replaces the builder when they leave? If the answer is "another ops person," Zapier or Make are the lowest-cost handoffs. If the answer is "an engineer," n8n is fine. If the answer is "the AI platform's support will help," Lindy is acceptable but you should price in the rebuild risk.

The Platform Selection Matrix (Filled In With Arithmetic)

Now run the four-question test against a concrete workload. We'll use a real one: route inbound leads from a webhook to the correct Salesforce owner, with a duplicate-check, a territory lookup, and a Slack notification, running roughly 1,500 times per month with three steps per run that count as tasks/operations.

That workload, with Zapier's task counting, is approximately 4,500 tasks/month. With Make's operation counting (each module call is one operation), it is closer to 6,000 operations. With n8n's execution counting (one workflow run = one execution regardless of steps), it is 1,500 executions. With Lindy's pricing, which is closer to "credits per action," the number depends on how AI-heavy the routing logic is.

Cost arithmetic

• Zapier Professional ($19.99/month, 750 tasks): at 4,500 tasks, you need the 5,000-task tier. The Professional plan tops out at 2,000 tasks before scaling, and at 5,000 tasks the Professional cost is around $73-$103/month depending on annual vs monthly billing. Adequate.
• Make Core ($9/month, 10,000 operations): 6,000 operations fits comfortably under the $9 plan. Cost: $9/month.
• n8n Cloud Pro ($60/month, 10,000 executions): 1,500 executions fits comfortably. Cost: $60/month. Or self-hosted on a $15/month VPS: $15/month plus your time (see Lesson 2).
• Lindy: AI-native pricing is per-action and per-credit; for a workload this size, expect $50-$200/month depending on AI density. Less predictable than the others.

At this volume, Make is the cheapest by a wide margin. n8n self-hosted is competitive once you account for time. Zapier is 3-10x more expensive. Lindy is in the middle but with variance. Cost alone says Make.

But cost is not the only axis

Apply Q1-Q4:

• Q1 (data sovereignty): if the inbound leads include PII regulated under GDPR and your DPA list doesn't include Make's subprocessors, Make is off the table for this workload. Move to n8n self-hosted.
• Q2 (code escape): if territory lookup involves a complex hierarchical match that doesn't fit a single Make formula, you'll want n8n's Code node or Zapier's Code step. Make is workable but more annoying.
• Q3 (AI-native): if the routing logic is "score the lead with an LLM and decide owner based on score," every platform handles this as a step. No advantage to Lindy.
• Q4 (team skill): if the maintainer is an ops manager, Zapier or Make. If it's an engineer, n8n.

The decision crystallizes from the matrix: an ops manager building a non-regulated routing workflow ends up on Make. The same workflow with regulated data ends up on self-hosted n8n. The same workflow on an engineering team ends up on n8n by default. The same workflow with "the agent decides everything" semantics ends up on Lindy or pushes back into n8n with explicit agent patterns.

The Zapier Lane: Maximum Connector Coverage, Maximum Onboarding Speed

Zapier wins three scenarios cleanly:

1. The connector exists nowhere else. Zapier has connectors for tools that Make and n8n haven't built yet. If your workflow touches a niche SaaS that only Zapier supports, Zapier's the path of least resistance. Check: is the connector officially supported, or is it a community zap? Community zaps break with platform changes.
2. The team is non-technical and the workload is small. Pro plan at $19.99/month with 750 tasks handles a surprising amount. Two zaps running 250 times/month each fits comfortably. You'll cross the threshold around 1,500 tasks where the upgrade to 2,000 tasks ($39/month) makes sense.
3. The workflow is <100 tasks/day and lives forever. Once a Zap is set up and running quietly, the maintenance cost approaches zero. The connector quality is high enough that breakages are rare.

Zapier's failure modes

Zapier becomes indefensible at high volume. The Team tier starts at $499/month for 50,000 tasks (see Lesson 3 for the exact arithmetic on when this becomes the migration trigger). Zapier's task-based pricing is brutal for "many small steps" workflows — the kind n8n and Make handle for a fraction of the cost. Zapier's Code by Zapier step is limited; complex transformations push you toward external functions. And Zapier's agent primitives are still maturing — for AI-native workloads, you'll likely outgrow Zapier's AI features within a year.

The Make Lane: Operation-Cheap, Visually Powerful, Less Forgiving

Make wins when:

1. Volume is moderate to high and ops cost matters. 10,000 operations for $9/month is dramatically cheaper than Zapier's equivalent volume. A workload running 50 times/day with five steps each = 7,500 ops/month, fitting comfortably in the $9 plan.
2. The team is visual-thinking and disciplined. Make's scenario builder is gorgeous and lets you see the data flow. The cost is that Make has more sharp edges — error handlers, iterator/aggregator semantics, and module routing all require more thinking than Zapier's "trigger → action" model.
3. Most data is structured. Make's data mapping is excellent for JSON-shaped flows. It struggles more than n8n with binary data and complex nested merge/split patterns.

Make's failure modes

Make's error handling is more complex than Zapier's. Make's debugging — particularly around what counts as an operation and why — surprises new builders. Make has fewer integrations than Zapier (still thousands, but a noticeable gap for niche tools). And Make's enterprise tier pricing escalates non-linearly. For data-sovereignty workloads, Make has no self-host option — your data passes through Make's infrastructure regardless of the plan.

The n8n Lane: Open-Source Sovereignty, Engineer-Friendly, Operator-Tolerable

n8n wins three scenarios cleanly:

1. Data sovereignty is required. Self-hosted n8n on your VPS or Kubernetes cluster keeps every byte inside your perimeter. n8n is the only one of the four with a credible self-host story. EU customers with strict residency requirements default to self-hosted n8n.
2. The team has at least one engineer. n8n's Code node, Function node, and custom-node extensibility let engineers do things that would require external functions on the other platforms. The handoff between visual-builder and code is the smoothest in the category.
3. Cost optimization at high volume. Self-hosted n8n on a $15/month VPS handles tens of thousands of executions/month without per-task or per-operation pricing. Once you cross the threshold where Make's $9/$29/$99 tiers start scaling, n8n's marginal cost is essentially zero (until you hit infra ceilings).

n8n's failure modes

Self-hosting means you are on call for the platform. Database backups, version upgrades, security patches, scaling — these are now your problem (see Lesson 2). n8n's UI is improving but still feels engineer-built. The integration catalog is large but smaller than Zapier's. And the AI/agent primitives, while strong, are still maturing relative to Lindy's native-AI approach. n8n is the right answer for "we'll build it once and live with it," and the wrong answer for "we want to spin up ten experiments this week."

The Lindy Lane: AI-Native, Agent-First, Fast-Moving

Lindy wins when:

1. The workload is genuinely agent-shaped. The system needs to loop, reason about which tool to call next, manage state across iterations, and decide when it's done. Lindy's primitives map cleanly to this. Other platforms are workflow engines coerced into agent patterns.
2. Speed-to-first-demo matters more than long-term maintenance. A two-day Lindy build can do what a two-week n8n build does. If you're prototyping or pitching, Lindy is fastest.
3. The team is comfortable with natural-language definition rather than visual graphs. Lindy leans into "tell the agent in English what to do" rather than "draw the boxes." Some operators find this liberating; others find it harder to debug.

Lindy's failure modes

Lindy's pricing has been moving — credits, actions, AI-density factors. Predictable budgeting is harder than on Zapier/Make/n8n. Lindy's data-sovereignty story is the weakest of the four; no self-host option. Lindy's audit logs are still maturing for compliance-heavy use cases. And as an AI-native vendor, Lindy ships schema changes faster than incumbents — your automations need maintenance attention.

Three Workloads, Three Platforms (Worked Examples)

Workload A: Daily customer-success digest from CRM data

An ops team pulls Salesforce data, runs an LLM summary of "what changed for top accounts," posts to Slack daily. Volume: one run per day, twenty steps per run. Sensitivity: medium (customer names, deal values). Team: two ops folks, no engineer.

• Q1 data sovereignty: account names and deal values are confidential but not regulated. Cloud SaaS acceptable if subprocessor list includes OpenAI/Anthropic.
• Q2 code escape: minimal — formatting and an LLM call.
• Q3 AI-native: the agent is a step (summarize this JSON). Not the system.
• Q4 team skill: ops folks, no engineer.

Verdict: Make. $9/month, ~20 ops/day = 600 ops/month, well inside the Core plan. Visual scenario, easy handoff, no engineering required.

Workload B: Patient-record-aware appointment-scheduling agent for a small clinic

The agent reads patient records, checks insurance eligibility, books appointments. Volume: 50 interactions per day. Sensitivity: HIPAA. Team: one tech-savvy practice manager.

• Q1 data sovereignty: HIPAA. Patient records cannot transit through a SaaS without a BAA.
• Q2 code escape: moderate — insurance-eligibility logic.
• Q3 AI-native: the agent is the system. It reasons about availability and patient context.
• Q4 team skill: one tech-savvy person.

Verdict: self-hosted n8n. The data-sovereignty requirement eliminates Zapier, Make, and Lindy. The agent-system shape is workable in n8n with its agent primitives. The team-skill constraint is real — the practice manager will need a part-time technical partner for the VPS, backups, and upgrades. Budget for that, or partner with a clinical-tech integrator.

Workload C: Inbound sales-lead enrichment and routing

Webhook arrives, agent enriches the lead from Clearbit, looks up territory, assigns to a rep, posts to Slack. Volume: 100 leads/day. Sensitivity: business data, no PII regulated. Team: an SDR-ops manager.

• Q1 data sovereignty: low concern.
• Q2 code escape: moderate — territory lookup may need a Code step.
• Q3 AI-native: agent-as-step.
• Q4 team skill: ops manager.

At 100 leads/day with five steps each, that's 15,000 tasks/month — over Zapier's 5,000-task Pro tier (requires Team or higher), or 15,000 ops/month on Make ($29 Pro plan), or 3,000 executions/month on n8n Cloud Pro ($60). Verdict: Make Pro at $29/month is the cheapest acceptable option with the right team-skill match. If the team had an engineer, n8n self-hosted would also be a strong choice.

The One-Hour Selection Process

Sit down with the workload description, the four questions, and a timer. Here's the structure:

1. Minutes 0-10: describe the workload in plain English. Volume per day, steps per run, sensitivity of data, AI-vs-deterministic ratio, who maintains it.
2. Minutes 10-25: answer Q1 (data sovereignty). If yes, you're on n8n self-hosted; skip to Q2 for code-escape confirmation. If no, all four are candidates.
3. Minutes 25-35: answer Q2 (code escape). Rate the workload's code requirements 1-5. If 4-5, n8n. If 2-3, Zapier or Make. If 1, any.
4. Minutes 35-45: answer Q3 (agent shape). If the agent is the system, Lindy or n8n with explicit agent patterns. If the agent is a step, anything.
5. Minutes 45-55: answer Q4 (team skill). Map the maintainer to the platform's median user.
6. Minutes 55-60: compute the cost at expected volume. Verify the verdict makes sense given your budget. If it doesn't, revisit Q1 (sometimes self-host is cheaper) or Q4 (sometimes a different maintainer changes the answer).

At the end of the hour, you should have a one-sentence verdict: "For workload X, we ship on platform Y, paying $Z/month, maintained by person W." If you can't write that sentence, you haven't finished the test.

When to Pick Two Platforms (and When Not To)

Mature operator-builders end up running two platforms: one for the long tail of simple zaps, and one for the heavy-lifting agents. A common combo is Make + n8n: Make for the cheap, high-volume connector glue, and n8n for the regulated, agent-shaped, or code-heavy workloads. Another combo is Zapier + Lindy: Zapier for the well-established workflows where the connector catalog is decisive, and Lindy for the genuinely AI-native pilots.

Avoid running three or four platforms unless you have a platform team. The operational overhead — credentials, secrets, observability, on-call — does not scale linearly. Two is the sweet spot for most operator-builder teams. One is fine if you're early.

The best operator-builders don't pick a tribe. They pick the right platform per workload and live with the fact that "right" varies. The four-question test gives you a defensible verdict you can articulate to a CFO, a CISO, and a successor.

Key Takeaways

• The platform decision is structural, not tactical. The wrong choice costs eighteen months of rebuild, not a monthly subscription.
• Run the four-question test per workload, not per company. Different automations can defensibly live on different platforms.
• Q1 data sovereignty: if data must stay inside your perimeter, n8n self-hosted is the only option of the four.
• Q2 code escape: n8n has the smoothest code-to-visual handoff; Zapier's Code by Zapier is adequate for short transforms; Make is more constrained; Lindy bets on natural-language.
• Q3 AI-native primitives: if the agent is the system (loops, tool choice, state), Lindy is built for it; if the agent is a step inside a deterministic flow, any platform works.
• Q4 team skill: match the platform to the median maintainer, not the most senior. The successor has to read it.
• Cost arithmetic at typical volumes: Make $9/10K ops dominates the low-volume lane; Zapier Pro $19.99/750 tasks is for connector coverage; n8n Cloud Pro $60/10K executions or self-hosted at $15/month VPS for sovereignty and high-volume; Lindy variable per-AI-density.
• Two platforms is the sweet spot for mature operator-builders. Make+n8n or Zapier+Lindy are common pairings. Avoid three or four unless you have a platform team.
• You should be able to write a one-sentence verdict in 60 minutes. "For workload X, ship on platform Y, $Z/month, maintained by W." If you can't, finish the test.