Three workflow automation platforms, very different architectural positions. This guide explains how Integration Platform as a Service actually works under the hood, where each platform's strengths lie, the role of native AI nodes, and how the Model Context Protocol is reshaping the integration layer of the AI stack.
Workflow automation — the discipline of connecting business systems through configurable rules, triggers, and actions — has matured into a USD 35 billion global category according to Grand View Research ↗, with a projected CAGR above 23 percent through 2030. The arrival of large language models as first-class nodes inside these platforms has accelerated adoption substantially: tasks that previously required custom code — classification, summarisation, extraction from unstructured text — are now drag-and-drop operations.
The three platforms most commonly evaluated by New Zealand and Australian businesses are n8n (open-source, self-hostable, German-origin), Make.com (closed-source, formerly Integromat, Czech-origin), and Zapier (closed-source, US-origin, the category originator). They occupy genuinely different architectural positions, and the right choice depends less on a feature checklist than on the shape of your engineering org and your data residency posture.
The category is technically known as Integration Platform as a Service — iPaaS. Underneath the visual builder, every iPaaS platform is doing fundamentally the same thing:
The difference between platforms is largely in: how transparent the execution model is, what happens when something fails, how many integrations are pre-built, and — critically — where the execution actually runs.
n8n is open-source under a fair-code licence, with both cloud and self-hosted deployment options. Its visual editor produces JSON workflow definitions that can be version-controlled in git, exported between environments, and edited as code when needed. The platform is built on Node.js and runs on any infrastructure that supports Docker.
The structural advantage of n8n for engineering-heavy teams is that the abstraction is leaky in a useful way: you can write JavaScript or Python directly inside any workflow node, call arbitrary HTTPS endpoints, and bypass any built-in integration when its behaviour doesn't match what you need. The community node ecosystem on n8n's GitHub ↗ is large and active.
For New Zealand and Australian businesses with data sovereignty requirements (relevant for finance, medical, and government workloads), self-hosting n8n on AWS Sydney or Azure Australia East gives clean residency control — execution data, credentials, and workflow definitions never leave the region. The trade-off is operational: someone needs to maintain the infrastructure, manage upgrades, and handle scaling.
Make (formerly Integromat) sits between n8n and Zapier in both technical depth and ease of use. The visual builder is widely considered the best in the category — the connections between modules are explicit and the data inspector is excellent. Make introduced the concept of "scenarios" — branching, looping, error-handling workflows — into the prosumer iPaaS category, and the underlying execution model remains more sophisticated than Zapier's linear-zap model.
Make is cloud-only — there is no self-hosted version — and execution runs on Make's EU infrastructure. For Australian and New Zealand businesses with strict data residency requirements, this is a constraint worth understanding upfront. For everyone else, Make's combination of operational sophistication and visual approachability is genuinely strong.
Zapier created the iPaaS category and remains the breadth leader: over 7,000 native integrations ↗ — substantially more than the alternatives. For workflows that involve long-tail SaaS tools — niche CRMs, regional accounting platforms, vertical-specific software — Zapier is usually the only option that has a pre-built integration.
The trade-off is that Zapier's underlying execution model is the simplest of the three. Linear zaps (trigger → actions in sequence) cover the majority of use cases excellently, but multi-branch workflows, complex error handling, and long-running state are awkward. Zapier has been investing in "Zapier Tables" and "Zapier Interfaces" to extend toward application-platform territory, but the core remains a simple integration runner.
All three platforms now ship native AI nodes that wrap LLM APIs — most commonly OpenAI's GPT-4 family, Anthropic's Claude family, and Google's Gemini family. The technical mechanism is identical across platforms: the AI node makes an authenticated HTTPS request to the model provider, passes the prompt and parameters, and returns the response into the workflow.
This means: the LLM choice is independent of the iPaaS choice. You can run Claude inside n8n, Make, or Zapier with similar fidelity — see our Claude implementation service for the production architecture. What differs is the quality of the surrounding workflow primitives — error handling, branching, state — which is exactly the dimension on which n8n is strongest and Zapier weakest.
| If your situation is... | The pragmatic choice |
|---|---|
| You have an engineering team and self-hosting is normal | n8n self-hosted — best long-term TCO, clean data residency, no platform lock-in |
| You have technical operators but no dev team, and you want sophistication | Make.com — best balance of power and accessibility |
| You need to connect a long-tail of SaaS tools with simple flows | Zapier — unbeatable integration breadth, simple model |
| You have strict data residency (finance, health, government) | n8n self-hosted in NZ/AU region — only architecture that keeps execution local |
| Your workflows will scale to millions of executions per month | n8n self-hosted or custom code — iPaaS pricing on the cloud platforms compounds at scale |
"By 2026, more than 80 percent of enterprises will have used generative AI APIs, models, or deployed GenAI-enabled applications in production environments, up from less than 5 percent in 2023." — Gartner, Generative AI Hype Cycle 2024
The most common failure mode in iPaaS deployments is silent breakage — a workflow that ran successfully for months stops working when an upstream API changes, and no one notices until customers complain. The Postman State of the API Report ↗ documents an ongoing acceleration in API change rates across the SaaS ecosystem.
This makes observability — not feature count — the variable that most strongly predicts long-term iPaaS success. The questions worth asking of any deployed workflow are: is execution success/failure rate dashboarded? Are alerts wired up? Is there a documented runbook for the top three failure modes? Without these, every iPaaS deployment quietly degrades.
Anthropic's Model Context Protocol (MCP) ↗, open-sourced in late 2024, is reshaping the integration layer of the AI stack. Rather than every iPaaS building bespoke connectors to every SaaS tool, MCP standardises the contract through which LLMs access external data and tools. The early evidence — community MCP servers for Slack, GitHub, Notion, Google Drive, Postgres, and dozens of others — suggests this will substantially compress the integration moat that breadth players like Zapier have historically enjoyed.
For workflow architects in 2026, this means: native integrations are becoming less of a differentiator, and the quality of the surrounding workflow primitives (orchestration, observability, error handling) is becoming more of one.
If you are evaluating platforms for a specific use case, the most useful next step is to build the same workflow as a small proof-of-concept in two of the three and observe what happens when it breaks. The platform whose error handling you can live with is usually the right answer. Our workflow automation service covers the full architecture pattern, and custom AI solutions for cases where iPaaS hits its ceiling.
References
30 minutes, no pitch. We map your specific opportunity and tell you what's worth doing first.
Book a free 30-min audit