Back to discover
ArticlesWork smarterHungarian edition

Make or n8n? Compare them with one small automation

Turn one fictional enquiry into a row for review. A useful comparison checks how you build the steps, catch exceptions and keep the automation running.

Two automation rigs process matching test enquiries with missing-field, duplicate and error paths visible.
CurioFuse · AI-generated illustration
In this article

You want incoming enquiries to become rows in a review sheet. Make and n8n both provide visual automation with optional code. The useful choice is the workflow you can build, understand and repair—and, if necessary, host yourself.

Compare the parts you will actually use

| Need | Make | n8n |
| --- | --- | --- |
| Connect the steps | Visual app/data automation with custom code, according to its overview | Visual nodes with code, according to its overview |
| Trace a run | Scenarios document inputs/outputs and stored failed executions | A workflow connects nodes and starts on a trigger |
| Handle a technical failure | Error handlers attach failure handling to modules | A configured error workflow begins with Error Trigger |
| Run on your infrastructure | Verify deployment requirements with the provider for your intended setup | Self-hosting is a documented option alongside managed cloud |

If running on your own infrastructure is a requirement, n8n belongs on your shortlist. That recommendation does not establish lower cost: someone must own configuration, monitoring and updates. If deployment is not decisive, compare the exact app actions and field handling in the following small trial. This is a documentation-based comparison, without a hands-on product test.

Build one fictional enquiry from beginning to end

Create this input: request_id: demo-01; message: “I am Alex, alex@example.com. Please quote for eight laptops.” Use invented data in a test sheet. Check that the required app actions exist before connecting anything.

Build these steps in both tools: manual input → extract name, email and topic → validate fields → check request_id → add a review row. Add AI only to interpret the free text. Use an exact rule to prevent the same request_id creating another row.

Expected first output: demo-01 | Alex | alex@example.com | quotation | awaiting review. Keep the original message beside the extracted fields. Run a second invented request without an email address: the field stays empty and its status becomes missing email. Run demo-01 again: it should be identified as a repeat rather than silently creating a new enquiry. These are your intended results, not measured product performance.

Choose by the work needed to keep it usable

Inspect the values entering and leaving every step. Disconnect a test connection and check where the failure appears and how you are alerted. For n8n, test notifications in a separate, automatically triggered test workflow: the Error Trigger does not run for manual executions. An incorrect AI topic can still look like a successful run, so inspect that field separately.

Record setup effort, corrections, duplicate handling and the steps needed to recover from the broken connection. Prefer the tool whose run history and field mapping you can explain to the person maintaining it. A row appearing once is a useful milestone; reliable handling of a missing field and a repeated request is the more informative comparison.

Original CurioFuse editorial. A guide to explore and evaluate AI, without an implied product test.

Sources & standardsReport a correction