How to choose an automation stack that still works in a year

Why the wrong tool costs you twice

Picking an automation tool feels low-stakes until the bill or the rework arrives. Choose a per-operation SaaS platform for a flow that fires 50,000 times a month and your invoice quietly climbs past what a full-time hire would cost. Choose a simple trigger-and-action tool for a job with real branching logic and you end up with a forty-node diagram held together by one person's memory, the kind of fragile setup nobody wants to open.

The mistake almost always runs in one of two directions. Teams either over-build a two-step task into a codebase that needs a developer on call, or they cram genuine business logic into a no-code tool that buckles under it. Both are expensive, and both are avoidable with a few honest questions asked before anything gets built. That is the whole point of choosing deliberately: the tool is a means to an end, and the end is a workflow that runs without a human babysitting it.

We do this selection for every automation we build, and we do it out loud with you rather than behind a curtain. You should understand why a given flow lives in n8n and another in Zapier, because you are the one who owns and operates the stack after we hand it over.

The five questions that pick the tool

Before we touch a builder, we score the job against five factors. They sound obvious, but writing them down is what stops a project from drifting toward the shiny option. Volume tells you whether per-operation pricing will bankrupt the flow. Complexity tells you whether the logic fits in nodes or wants code. The systems in play tell you what integrations actually exist. Your team's comfort level decides who can maintain it after us. And total cost over a year, not the sticker price of a plan, tells you what the thing really costs to run.

Run any real workflow through those five and the answer usually picks itself. A lead moving from a web form into your CRM is low volume, low complexity, common systems: Zapier ships it in an afternoon. A nightly job reconciling 4,000 orders across three systems with retry logic is high volume and high complexity: that belongs in n8n or code. Most businesses end up with a blend, and knowing where each line falls is the value we add.

• Volume: how many times a month does it run, and does per-operation pricing punish that
• Complexity: simple trigger-and-action, or branching logic, loops, and data transformation
• Systems: do clean APIs and connectors exist, or is an integration going to be the hard part
• Team fit: who maintains and tweaks this after handover, and what can they actually read
• Total cost of ownership: license plus maintenance plus the cost of it breaking, over twelve months

n8n, Make, Zapier, and code: what each is actually for

There is no best tool in the abstract, only the right one for the job in front of you. Zapier is the fastest path for simple, low-volume triggers between popular SaaS apps; it is unbeatable when you need something moving today and the logic is a straight line. Make is a stronger visual builder for multi-step flows with branching and a deep library of app connectors, a good middle ground when a job outgrows Zapier but does not yet need engineering.

n8n is our default for anything with real logic and volume. It self-hosts, so your data stays on infrastructure you control and costs stop scaling with every task, and it runs custom JavaScript or Python inside a visual flow, so we keep the readable parts visual and drop to code exactly where it earns its place. Plain code comes out when the scale, the transformation, or a missing integration demands it. These are not rival camps to pick a side in; a single business often runs all four, each doing the part it is best at. The deeper trade-off between them is the no-code versus code question we cover in its own guide.

• Zapier: simple, low-volume triggers between common apps, live in hours
• Make: multi-step visual flows with branching and many connectors, no engineering needed
• n8n: real logic and volume, self-hosted, fair at scale, code-capable inside the flow
• Custom code: heavy transformation, tight performance, or an integration nothing else supports
• LLMs (Claude, GPT): dropped in as a step for classification, extraction, and drafting

Designing for ownership, not lock-in

The stack you choose also decides who controls your automation a year from now. Per-operation SaaS platforms are convenient until a pricing-page change doubles your bill or a workflow you depend on sits somewhere only the vendor can reach. That is why, for most clients, we lean toward self-hosted n8n: your data stays under your control, which matters under GDPR in Europe, and a high-volume flow that would cost hundreds a month on a metered plan runs for the price of a small server.

Ownership is the principle underneath the tool choice. When we build for you, you own the workflows, the code, the documentation, and the credentials, all running on your accounts and your infrastructure. If you ever want to bring it in-house or move to another partner, everything comes with you. Choosing a stack you can actually own is the difference between hiring a studio that ships you an asset and renting a black box you can never turn off. It is also why we document the reasoning, so the choice survives past the people who made it.

When to standardise, and when not to automate at all

A framework is not a licence to run five tools for the fun of it. Once you have a couple of proven platforms, standardising on them has real value: fewer accounts to secure, fewer things your team has to learn, and less surface area when something breaks at 2am. We usually settle a client on n8n as the backbone plus one lighter tool for quick wins, and reach outside that only when a job genuinely demands it. Boring and consistent is what survives contact with production.

The most honest answer we give is sometimes not to automate at all, or not yet. If a process runs a handful of times a month, changes shape constantly, or hinges on judgement a rule cannot capture, the automation will cost more to build and maintain than the hours it saves. We would rather tell you that upfront than sell you a flow you will switch off in three months. And when a workflow does span several tools, the connecting logic matters as much as the tools themselves, which is where our cross-tool integration work comes in.

• Standardise on one backbone plus one light tool once they are proven, to cut sprawl
• Do not automate a process that runs rarely or changes shape every month
• Skip automation where the outcome hinges on human judgement a rule cannot capture
• Prototype on real data before committing a tool, so the choice is evidence, not a guess