Zapier, Power Automate, or Something Built? How to Choose

There's a moment in most automation conversations where someone says "can't we just use Zapier for this?" It's a good question and it deserves a real answer, because sometimes the answer is yes, sometimes it's a subscription that grows every quarter, and the two look identical on day one.

This is the honest comparison: what the automation platforms are genuinely good at, where their pricing model turns into a tax, what "something built" actually means, and the five questions that decide it.

We sell automation work (Automation & Integration is one of our services), and we build on these platforms as often as we build around them, so treat this as an interested party's view. We've tried to write the version that's useful even if you never contact us.

What we're actually comparing

"The platforms" means the no-code and low-code automation tools — Zapier, Make, n8n, Microsoft Power Automate, and the automation features increasingly baked into software you already own. They all work roughly the same way: a trigger in one system, some steps, an action in another, configured through a web interface rather than written as code.

"Something built" is the other end, and it's a wider range than people imagine. It might be a scheduled database query that emails a report. It might be a fifty-line script on a timer. It might be a small service with its own logging and error handling. It is very often much smaller than "custom software" sounds.

There's no moral hierarchy here. The correct answer is whichever one you can afford to keep running.

What the platforms are genuinely good at

Four things, and they're not small:

Speed to first result. A useful automation in an afternoon, with no deployment, no server and no developer waiting on an environment. For proving whether an idea is worth anything at all, nothing beats it.

The connector library. The unglamorous, genuinely hard work of talking to hundreds of different products' APIs — handling their authentication, their pagination, their quirks — is already done. Rebuilding one connector can cost more than a year of the subscription.

Visibility for non-developers. Somebody who isn't technical can open the thing, see what it does, and often fix it. That matters more than it sounds: an automation only one person understands is a liability whichever way it was built.

They already own it. If you're on Microsoft 365, you very likely have Power Automate sitting there. Using what you've already paid for is almost always the right first move.

Where the pricing model becomes a tax

Platforms generally charge per task, per run, per step or per seat. That model is friendly at low volume and unfriendly at exactly the moment your automation becomes important.

The failure mode is specific and common: you build something that runs once per order. It works. The business grows, or you point it at a second data source, or a loop turns one run into fifteen steps. The bill moves from rounding error to a real line item, and because the thing now runs the business, nobody can switch it off to negotiate. You didn't buy a tool — you bought a variable cost that scales with your success.

Two smaller versions of the same trap. Per-seat pricing starts to bite when the automation needs to be visible to a whole department rather than the one person who built it. And the premium connector tier — the one where the systems you actually need live — is frequently the difference between the advertised price and your price.

None of this makes platforms a bad purchase. It makes volume a question you answer before you commit, not after. Ask what the bill looks like at three times today's volume. If that number is uncomfortable, you've learned something now rather than in eighteen months.

Where something built wins

High volume, simple logic. The clearest case. A job that runs constantly but does something straightforward is where per-task pricing is worst and where a small script is at its best. A scheduled query costs the same at ten runs a day as at ten thousand.

Logic the interface fights you on. Every platform has a ceiling. When a workflow needs real branching, careful error handling, or a calculation that ends up as six chained steps and a regular expression buried in a text field, you've passed it. Past that ceiling, a visual builder is harder to read than the code it replaced — and much harder to hand to the next person.

Data that shouldn't leave. Routing personal, financial or regulated data through a third party is a decision, not a detail. Sometimes it's fine. Sometimes the review costs more than the build.

Things that must not fail quietly. Platforms do have logging and alerting, and on the better plans it's good. But when an automation moves money or touches customers, you often want the failure behaviour designed rather than configured.

Portability. A workflow built inside a platform mostly stays there. A script in your own repository is yours, reviewable, and movable. Whether that matters depends on how load-bearing the automation becomes.

The five questions that decide it

Run these in order. Most cases resolve in the first two.

1. How often will it run? Low and predictable favours a platform. High or spiky favours something built.
2. Do you already pay for a platform that can do this? If yes, try it first. Proving the idea on a tool you already own is the cheapest experiment available.
3. Where does the data go? If it can't leave your systems, the decision is already made.
4. Who maintains it in a year? A non-technical team with no developer should lean toward the platform, even at a higher running cost. Something built with nobody to maintain it is worse than a subscription.
5. What happens if it stops? Mild inconvenience is a platform problem. A business that halts is worth designing properly.

Notice that only one of those is about technology. The rest are about money, risk and who's around to look after it — which is why this decision is rarely a developer's to make alone.

The answer most businesses land on

Both, deliberately split. Platforms for the long tail of small connections — notifications, form handoffs, the odd sync between two SaaS products — where the connector library earns its keep and the volume is low. Something built for the two or three automations that run constantly, carry risk, or sit at the centre of how the business works.

That split gets decided per automation, on the questions above, not once for the whole company. A blanket "we're a no-code shop" or "we build everything properly" is a policy, and policies are how businesses end up paying platform fees for a job a cron line would do, or spending three weeks building something a connector already handled.

One rule survives both paths: whatever you choose, it has to tell you when it fails. Silent success and silent failure look identical from the outside, and an automation that quietly stopped two weeks ago is worse than no automation at all.

Worth reading alongside this: what the work costs, because platforms and built solutions carry their cost in completely different places, and what to do when two systems won't talk to each other, which is the question underneath most of these decisions.

Before you pick either

You can't answer question one without knowing how often the work actually happens, which is the counting exercise — an afternoon with the people who do the work, and the tool question mostly answers itself afterwards.

Or let us do it: our free automation map takes five working days and gives you the manual work written down with hours against it, which of the tools you already pay for can talk to each other, and a build order. Free, nothing to sign, and no platform recommended before we know what it'd be running.

We'd rather you spent nothing and automated the right two things than bought a licence you have to justify.