n8n or Make: which should you choose for AI automation?

Choose n8n or Make by testing the process your team will operate: connections, permissions, human approval, recovery after errors and cost at your volume. For a hosted service, compare Make and n8n Cloud on the same process. If orchestration must run in your own environment, assess n8n with the person responsible for updates, backups and recovery.

This comparison uses capabilities and billing approaches documented by the vendors, consulted on 3 October 2026. It does not claim an executed comparison on both platforms. The worksheet prepares that trial without assigning fictional scores to either tool.

To work on your own project: open the 6-page PDF pack, then the editable workbook. They include a worked case, a conditional decision, a recalculating budget and seven acceptance tests to run. The complete kit combines these files with the technical worksheets. Case data is fictional; platform outcomes remain “not tested”.

What actually differs between the tools?

Both tools can organise steps across applications. An AI module alone does not resolve access, identity or approval questions. The choice also concerns where the process runs, how it is billed and who looks after it when it fails.

n8n plans and Make's credit documentation use different units. One thousand executions cannot therefore be compared directly with one thousand credits. An execution may pass through several steps, while AI-module consumption can also depend on the connection mode.

The n8n pricing page also distinguishes credits for its Assistant, which helps build workflows. Record those credits, workflow executions and usage of the model called by the workflow separately: they are different cost items.

Hosting the orchestrator yourself does not mean everything stays local. If a step calls an external model, examine that transfer separately. Our private versus public AI guide helps frame architecture questions.

How do you eliminate an option before comparing price?

First verify the exact connector action under your permissions, then data destinations and recovery. A connector appearing in a catalogue does not establish support for the expected field, volume or approval mechanism.

When something is missing, price the adaptation instead of assigning an arbitrary score. Another API call, external approval or manual review may be acceptable if their cost and owner are known. A write without approval, forbidden access or a retry that creates a duplicate should block the pilot until corrected. A good price score cannot compensate for a failed mandatory requirement.

Which small process should you use for comparison?

In the PDF’s worked case, a maintenance company receives DEM-104: “our reception computer will not start; could you visit on Tuesday morning at Rouen Centre?”. Contact C-042 has one match in the test dataset and record version 7. The expected result is an intervention draft linked to DEM-104, after approval of proposal p1. The requested time remains text: no confirmed date, price or diagnosis is invented. A changed record requires fresh approval before writing. This fictional pilot sends no customer message.

The fictional team already knows Make and accepts a hosted service, so it starts with a Make pilot, subject to all seven tests. A team already using n8n would start with its existing environment; without an existing tool, compare Make and n8n Cloud. A requirement to host orchestration in your own environment leads to assessing self-hosted n8n with a named operator. These criteria determine a testing order, not a performance ranking.

Use a fictional customer request: receive it, interpret the need, find a contact, prepare an action, obtain approval and write in a test environment. Supply identical inputs and require identical expected outcomes on both tools.

The test plan covers a valid input, an ambiguous identity, an unavailable API, a repeated event and a record changed while approval is pending. The two recovery and approval tests supplement that plan. Results stay blank until the test has run: an expected outcome is not evidence of success.

What should you test when a step fails?

Suppose fictional request DEM-104 is approved. The CRM creates a record, but its response is lost. The automation sees a timeout; that does not tell you whether creation succeeded. Retrying the step unchanged may create a second record.

Before the first write, provide a stable reference linked to the request. During recovery, look up that reference in the destination: if the record exists and matches the approved action, record its identifier and continue without recreating it. If the state is uncertain or the lookup is unavailable, send the request for review. A simple "search, then create" is insufficient against simultaneous retries: the destination also needs a mechanism preventing duplicates, or supervised recovery that avoids concurrent writes.

Make documents several error handlers, but their names do not describe all their effects. Its Rollback applies to transaction-capable modules and depends on the auto-commit setting; it cannot undo every external action, such as an email already sent. Check the actual operation, its settings and the target application's state.

The SQLite demonstration in the CRM guide illustrates recognising a completed write. It is independent of n8n and Make. The two cases above are a protocol to run against your connections, not results obtained on those platforms.

What should you count in a branching workflow?

Separate business requests, model calls, human approvals and write attempts. These quantities describe the process; they do not convert directly into Make credits or billed n8n executions.

Our fictional sizing scenario receives 1,000 requests. Each uses one model call, and 200 need detailed review under the exercise's chosen rule. Every request remains subject to the required approval before writing. Of 1,000 initial write attempts, 50 fail before creating anything and are retried once: 1,050 attempts in total. If the model output was retained and remains valid, those retries do not require fresh AI reasoning.

The sizing worksheet makes assumptions explicit. It does not measure n8n or Make operation. A failure elsewhere, a stale output or a different retry strategy can change the counts.

How do you compare costs without confusing units?

Record the number of inputs, branches actually followed, model calls and retries. Then apply the relevant commercial plan, currency, commitment period and potential overages. Recheck prices and capabilities when deciding, using the Make pricing page and n8n's page.

Your budget also includes design, hosting where you operate it, maintenance and human review. For AI, check whether model consumption is included in credits or billed by a separate provider. Avoid both double-counting and omitting that cost.

The working formula is: setup cost allocated over the period + subscription + variable consumption + operation + human review. The measurement log provides one row per test path and tool: request, execution, outcome, billed units, human time and evidence. Record the observed counter and dated plan; do not infer credits just from the number of blocks on screen. Separate completed, rejected and pending requests so that a process which drops work does not appear artificially cheaper.

Worked budget: how much does review time cost?

Consider a fictional budget unrelated to n8n or Make prices. Assumptions: 1,000 requests a month, 30 seconds of review per request, an internal hourly cost of €36 and €200 a month for other items. Here, the €200 groups allocated setup, service, usage and operation to isolate the effect of review time.

Human review takes 1,000 × 30 / 3,600 = 8.33 hours, costing €300. The working monthly budget is therefore €500. At 90 seconds per request, review takes 25 hours and costs €900: the total becomes €1,100 with all other assumptions unchanged.

The budget assumptions worksheet details both scenarios. These amounts are neither an Initial IA quotation nor vendor price estimates. In your own budget, separate the grouped items and check whether any rise with volume. Freed human capacity does not automatically create cash savings.

How do you decide after the pilot?

Start with mandatory requirements. An unexecuted case remains "unverified"; a permission, approval or duplicate error requires correction and another test. Agree this proposed rule with the business owner before the pilot.

For solutions passing these checks, compare the same completed scope: approval and recovery time, service costs, connection maintenance and an available owner. Retain results per case as well as totals. A reassuring average can hide a few requests that take a long time to fix.

A cheaper subscription can cost more to operate. In a fictional example unrelated to either vendor, saving €60 a month on the service while adding two maintenance hours at €60/hour means €120 of extra work and a total cost €60 higher. This compares assumptions; it does not predict the cost of your installation.

What should you hand over with the decision?

Have another person recover a failed case using the documentation alone. They should be able to find the request, determine what has already been written and identify the permitted action. If they must ask the workflow author at every step, handover is incomplete.

The decision record brings together the tested scope, results, costs, reservations, owner and backup person. It offers three outcomes: proceed within this scope, correct and retest, or reject the option. Also record when to reopen the choice: a change in volume, connection, model or permissions that affects the outcome. Another team should be able to understand the decision without repeating the entire investigation.

Your decision: can attempts be converted into credits?

Fictional case: your process assumes 1,000 requests and 50 retries after failures before writing. Someone proposes budgeting exactly 1,050 Make credits and 1,050 n8n executions. Is that supported?

• A. No: these are operational attempts; measure billed units for the actual process.
• B. Yes: an attempt always equals one billed unit.
• C. Yes, provided the AI model is identical.

Read the explained answer

A. The 1,050 attempts describe an operating assumption, not a shared commercial unit. Record the process, branches, calls and observed usage under the applicable offer. The review calculator then adds human time to the budget; its fictional amounts are not vendor prices.

Adapt this: which items are included in your subscription and which must be measured separately?

Try your assumptions in the calculator. Calculations stay on your device; no data is sent.

Does the process need AI? Not to copy an already structured field. A rule may suffice; interpreting a free-form request may justify an AI step.

Can you choose by connector count? Check the precise operation instead. Reading a contact, identifying it unambiguously and modifying only permitted fields are three distinct requirements.

Initial IA can scope this integration using your inputs, tools and expected result. Before comparing platforms, check that you have chosen a sufficiently specific first task.

Written by Initial IA, 26 September 2026. Expanded on 27 September 2026. Sources and budget reviewed on 3 October 2026. Documentary comparison with a supplied trial protocol; no performance ranking or estimated market price.