Power Automate, Zapier, Make, n8n — and why I usually build the integration instead

I support all four and I'll happily work in yours. But after twenty years of wiring systems together, the honest answer is that a custom integration is now more robust, more flexible, and often faster to build than assembling the same thing out of connector boxes.

Every automation project starts with the same question: which tool should we use?

Here's my honest answer, and it isn't one of them.

These platforms were designed for a world where writing an integration was expensive. Somebody had to read two sets of API docs, hand-write the auth, handle pagination and retries, and maintain it forever. Against that cost, paying a vendor for pre-built connectors was obviously correct.

That world ended. The expensive part — the plumbing — is now the cheap part. And once the plumbing is cheap, the trade you make when you adopt a connector platform stops being worth it.

What you're actually trading away

You inherit their model of your problem. Connector platforms give you the fields the vendor decided to expose. The moment your business rule doesn't fit — a conditional approval, a lookup against a third system, an exception for one customer who's billed differently for historical reasons — you're building a workaround inside a visual editor that was never meant to hold logic.

The cost scales with your success. Zapier meters per task, and a "task" is each step, not each automation. A five-step Zap firing 500 times a month is 2,500 tasks. People price the tool against 500 and get invoiced for 2,500. Power Automate's premium connectors have their own licensing cliff. Your bill grows precisely when the automation is working.

Debugging is a black box. When a run fails at 2am you get the platform's error, not your error. You can't put a breakpoint in someone else's connector, you can't add a log line where you need one, and you can't write a test for the branch that broke.

Nobody can read it in a year. A complex flow is a diagram. Diagrams don't diff, don't code-review, and don't tell you what changed. I've inherited flows that nobody at the company could explain, built by someone who left.

What a custom integration actually costs now

This is the part that's changed, and most people haven't updated their mental model.

Writing a typed client for the QuickBooks API — mapping their field names to yours, handling pagination, token refresh, rate limits — used to be two days of documentation archaeology. With an AI coding agent it's an afternoon. The work is well-specified, tedious, and heavily represented in training data. It's the single best-fit task for these tools.

So the comparison is no longer "two weeks of engineering versus an afternoon in Zapier." It's closer to a day either way — and at the end of that day, one path gives you:

Your logic, in code, that you can read, test, version, and diff
Real error handling — retries with backoff, dead-letter queues, alerts that say what actually broke
Fixed hosting cost instead of per-task metering
No connector ceiling. If the API supports it, you can do it
Something a competent developer can pick up cold because it's a repository, not a canvas

That's not a close call anymore. That's why my default is custom.

When I still reach for the platform — and I do

I'm not religious about this, and I support all four.

Power Automate, when the work lives entirely inside Microsoft 365. If the trigger and the destination are both Microsoft — an approval in Outlook, a file in SharePoint, a post in Teams — use it and stop shopping. Not because it's the best-designed tool, but because everything else is fighting the authentication model. You'll spend more time on Graph tokens elsewhere than you'll save in licensing.

Zapier or Make, when the person maintaining it isn't technical. This is the real one. If the honest answer to "who owns this in eighteen months?" is "the office manager," then a clean, well-named Zap she can read beats an elegant service she can't. The best automation is the one that's still running and still understood — and I've watched a beautifully engineered n8n instance become unmaintainable the day its author left.

Any of them, for a genuine two-step. New form entry creates a CRM record. That's it. Don't build a service for that.

n8n, when you want self-hosting and the data can't leave. If the workflow touches PII, PHI, or CUI, self-hosted stops being about cost and starts being about the data processing agreement you don't have to negotiate. Though at that point you're running infrastructure anyway — which is most of the argument for just writing the service.

The pattern I actually deploy

For a typical client this ends up as a hybrid, and the split is deliberate:

Power Automate for the Microsoft-native paths — approvals, file routing, Teams notifications. Things where the platform genuinely is the shortest distance.
A small custom service for anything with real business logic — called from the flow over HTTP where a flow is already involved.
Nothing at all where the answer is "fix the process." If a handoff is broken because nobody agreed who owns a step, new software just encodes the confusion at higher speed.

The low-code tool handles what it's genuinely good at. The 10% that's actually hard lives in code you can test.

Where AI belongs inside any of this

All four platforms now ship LLM nodes, and they're useful for a narrow set of jobs: classification ("is this inbound email a support request, an invoice, or noise?"), extraction (pulling structured fields out of unstructured documents), and summarization into a digest.

What they're bad at is anything where a wrong answer silently proceeds. If a model decides an invoice is $1,500 instead of $15,000 and the next step pays it, you've automated a loss. Put arithmetic validation and a human approval gate on anything that moves money or touches a customer — and note that "put a validation layer here" is much easier to do in code than in a connector box.

The takeaway: these platforms aren't bad, they're priced for a problem that got cheap. Pick one when the work is Microsoft-native, genuinely trivial, or owned by someone non-technical. Otherwise build it — you'll get something more robust, more flexible, and cheaper to run, in about the same amount of time. If you already have flows running, I'll work in them. I'd just rather show you what the custom version costs before you renew.