Zapier, n8n, or bespoke: picking your automation layer.

You have decided what to automate, and the next question is what to run it on. That usually gets answered by whichever tool somebody in the business has heard of.

We wrote about build versus buy in general terms earlier this year. This is the narrower version of that decision: not whether to commission software, but which layer the automation itself should live in. The right answer differs between two jobs in the same business, and picking one tool for everything is where most of the regret comes from.

What the three actually are

A connector tool such as Zapier is a hosted service that watches for an event in one system and takes an action in another. You configure it in a browser, it runs on somebody else's infrastructure, and you pay by task executed or by month depending on volume.

A self-hosted workflow tool such as n8n does much the same job through a visual editor, except that you can run it on your own server. That changes the cost shape and the data picture, and it gives you something to look after.

Bespoke means code written for your business, running wherever you put it. No editor, no library of ready-made connections, and no ceiling on what it can do.

These are not three points on a line from cheap to expensive. They are three different distributions of cost, and the usual mistake is comparing invoices rather than totals.

When a connector tool is enough

Connector tools are enough more often than people who enjoy this subject admit. If the job is a handful of steps between systems that both have decent integrations, if the volume is modest, and if nobody in your business wants to think about servers, it is the right answer. It will stay the right answer for years. Setup takes an afternoon and it runs by the end of the day. That matters more than it sounds, because a thing running today is what teaches you whether it was worth doing.

The honest limits are three. Cost scales with volume, so at high task counts the monthly figure stops looking small. You are bound by which connections exist and what those connections expose, which is generally less than the underlying system can do. And your data passes through a third party, which for most businesses is unremarkable and for some ends the conversation.

The test is simple: if your automation is a few steps, runs hundreds of times a month rather than hundreds of thousands, and touches nothing that would trouble you in somebody else's hands, stop reading and go and build it.

When self-hosting earns its overhead

A self-hosted workflow tool removes two of those three limits, and only two.

It removes cost at volume, because you pay for a server rather than per task, and the difference turns serious somewhere above a few thousand runs a month. It removes the data question, because everything can stay on infrastructure you control, which is what makes it the usual answer where personal or clinical records are involved. It does not remove the connector ceiling, though the ability to drop a small piece of custom code inside a workflow goes a long way towards it.

The cost is that you now run software, so something has to update it, restart it when it stops, and notice when it has been quietly failing for a week.

The cost is that you now run software, so something has to update it, restart it when it stops, and notice when it has been quietly failing for a week. In a business with somebody technical, that is a small standing cost and the trade is frequently worth making. In a business without one, it is a new dependency on a single supplier or a single person, and it is worth being honest that you have created one.

A reasonable rule: self-hosting earns its place when volume makes the connector bill uncomfortable, or when the data cannot leave, rather than because it looks cheaper on paper. It is only cheaper if the time to look after it is worth less than the difference.

When it has to be built

Bespoke earns its place in a narrower set of cases than most people commissioning it believe.

The first is when the logic is the point. Not moving data between systems, but doing something particular to how your business works, with enough branching and enough exceptions that a visual editor becomes harder to read than code would be. Past a certain complexity a workflow diagram is code anyway, except that nobody can review or test it properly.

The second is when it has to be verifiable. Some processes must produce the same result every time and be provable afterwards. Version control, a test suite and a proper log are ordinary in code and awkward to reproduce in a builder.

The third is when there is nothing to connect to. If the system at one end has no API, the connectors do not exist and no tool conjures them.

And it is worth saying plainly where bespoke is the wrong answer: straightforward movement between well-supported systems. Writing that in code produces something doing exactly what a connector does, at a higher cost to build, which you now maintain. That is the most common bespoke mistake we see, and it usually starts with asking a developer what they would do rather than what the business should.

How this usually goes wrong

It is rarely one bad decision. Usually it is picking a layer once, early, then bending everything afterwards to fit it, because switching feels like conceding a mistake.

Most businesses this size end up with a mixture, and that is the correct outcome rather than a sign of drift. A connector tool for the ordinary flows between systems, something self-hosted where volume or data demands it, and a small amount of bespoke code where the logic is genuinely yours. Judge each automation on its own terms, and be willing for the answer to differ from the last one.

The next step is an inventory rather than a platform decision. List what you automate today and what you want to, then mark each one with the layer it belongs in and why. Lists that come back entirely bespoke or entirely connector are usually the ones where somebody chose before they counted.

We build across all three layers, and the one we recommend most often is the cheapest that will hold. We would rather set up a connector tool you can maintain yourself than build something that keeps you dependent on us.

Azeem Hadi, founder of Baseops

Azeem Hadi

Founder @ Baseops. I've been crafting websites, creating brands and building systems for nearly 20 years.

Got a project in mind?

Or just want to talk through an idea? We are always happy to chat, no strings attached.

Thirty minutes, direct with the founder. No pitch deck.