n8n vs Make Automation Stack: A Pre-Build Checklist

Make's pricing page lists 1,000 credits a month on its free plan, and n8n's pricing page lists €20 a month for 2,500 executions on its Starter plan with annual billing. Those two numbers say almost nothing about which tool belongs in your business. Choosing an n8n vs Make automation stack for a plumbing, HVAC or roofing company comes down to four questions we ask before we build anything. We have already compared the two tools by workflow complexity in n8n vs Make for small trades companies. This article takes a different angle: the checklist we run before the first workflow exists.

n8n vs Make automation stack: start with the job, not the tool

Most owners ask us which tool is better. That is the wrong first question, because both tools can move a form submission into a CRM and text a dispatcher on day one. The difference shows up three months later, when a step fails on a Friday evening and nobody knows.

Our opinion, stated plainly: Make is the right default for a short, linear job that one person will own. n8n is the right choice when the workflow branches, calls AI models, or has to run under your control. Custom code is for the narrow case where neither tool can express the logic.

Vendor-neutral comparison tables hide this, because they list features and skip consequences. A feature you never use does not matter. A failure nobody sees matters a lot.

So we do not start by opening either tool. We start with four questions: who finds out when the workflow breaks, what one customer request costs to run, who owns the server and the license, and what you already pay for. The answers usually point to one tool within a short conversation.

Question one: who finds out when it breaks?

Every automation fails eventually. A CRM connection expires, a website form gains a new field, a customer types a phone number with a typo. For a trades company the damage is quiet: the inquiry goes in, nothing happens, and the customer calls the next company on the list.

Both tools can handle this. n8n's docs say you can set an error workflow for each workflow, and that it runs when an execution fails. That error workflow starts with an Error Trigger node, which receives the execution ID, the error message and the node that caused the failure. A Stop and Error node lets you fail on purpose, for example when a phone number arrives blank.

Make's help center lists error handler routes and the directives Ignore, Resume, Commit, Rollback and Break, along with exponential backoff, which retries a failed run with growing delays. For a simple scenario this is readable right on the canvas.

The real question is whether somebody builds the alert. Our rule is that no workflow ships without a failure path that reaches a named human, in plain language, not a stack trace. If one tool makes that path harder for the job at hand, that counts against it.

Question two: what does one customer request cost to run?

The two tools bill in different units, and that matters more than the sticker price. Make's pricing page says each action a scenario performs consumes credits, that most actions use 1 credit, and that the free plan includes 1,000 credits a month. n8n's pricing page defines an execution as a single run of the entire workflow, no matter how many steps it has or how much data it processes.

The same page lists Starter at €20 a month for 2,500 executions and Pro at €50 a month for 10,000 executions on annual billing, and says monthly billing costs 17 percent more.

Here is what that means in practice, without inventing numbers. Take a workflow with ten actions. Under Make's one-credit-per-action rule for most actions, each customer request uses about ten credits. On n8n the same request is one execution. A two-step workflow is cheap on either tool.

At small volume, price rarely decides the choice, so we do not pick a tool on price alone. It starts to matter when workflows get long, or when follow-up sequences run repeatedly for each customer request. Check both pricing pages before you sign, because plans change.

Question three: who owns the server and the license?

n8n can be self-hosted, and that is part of its appeal. Its hosting docs recommend Docker for production, and they leave infrastructure, updates, security settings and monitoring to you. Self-hosting is not free in any sense that counts: you pay with attention.

The license matters too. The Sustainable Use License in n8n's GitHub repository grants the right to use the software for your own internal business purposes or for personal, non-commercial use. An agency that runs one instance for several paying clients has to read that carefully. We do that for every setup, and we do not guess.

Our practical advice for a company with no IT person is simple. Do not self-host. Use a hosted plan, or use Make, and let someone else keep the servers patched.

If you do self-host, write down who is responsible for updates and backups, and who answers when the server is down. An unowned server is the most expensive free tool you can run.

Question four: what do you already pay for?

Many CRMs include a built-in automation builder. If yours can text a customer after a missed call, building that outside the CRM adds another login, another bill and another place to break.

Our order of preference is native first, Make when a job crosses two or three apps, and n8n when the job branches or calls an AI model. This order keeps the number of moving parts low, and fewer parts means fewer 6 p.m. surprises.

Our CRM and customer follow-up service starts exactly here: we look at what your CRM can already do before we propose anything new.

Outside tools earn their place when a job crosses systems, such as a website form, a CRM, a calendar and an accounting app. Our list of automations every service business needs shows which jobs usually justify that extra layer.

When we write custom code instead

Custom code is justified in three cases. The logic does not fit a visual canvas, such as dispatch rules with many conditions. A hosting or licensing requirement rules out both tools. Or the workflow has become a core part of how the business operates, and you want it versioned, tested and documented like software.

The price is maintenance. Code needs a repository, documentation and someone who can change it later. You also need to be able to hire a different developer without starting over. A visual workflow can be read by a non-programmer; code usually cannot.

Most small trades companies never reach this point, and we say so to clients who ask for custom work too early. Our AI automation workflows service begins with the tools and moves to code only when the tools get in the way.

A worked example: quote follow-up for a roofing company

Take a hypothetical roofing company with an estimate form on its website. The goal is simple: the form creates a CRM record, the customer gets a text, the owner gets an alert, and a customer who has not replied gets a nudge.

The form itself is part of the website, which our web design and development service covers. The nudge belongs in the CRM's own sequences, because that is a native job. The hop from form to CRM to calendar suits Make, because it is short, linear and easy for one person to own.

Now add an AI step that reads the message and sorts an emergency leak from a routine estimate. That adds branching and a model call, so that part moves to n8n. The failure path goes to the office manager's phone in every version.

We covered the follow-up logic in our quote follow-up guide, and phone inquiries in AI receptionist vs answering service. Notice that the answer was a mix of three tools, not one winner. That is normal.