n8n: a pretty wrapper that ate up two days

The client came with an idea: they have access to the level.travel API, hundreds of Telegram channels for travel agents, and a desire to automatically publish attractive tours on a schedule. Sounds like a typical automation task — take the API, pull JSON, process it, publish. I had already sketched how this would look in Python when the client added a requirement: use n8n. The team was sure it would simplify maintenance later — “everything is visual there, anyone can figure it out.”

I didn’t argue. I got to work.

Two days later I deleted all workflows and rewrote the logic in Python. It took a few hours.

This is not a story that n8n is a bad tool overall. This is a story about how a tool actively sells itself as a solution to problems it doesn’t actually solve — or solves so poorly that it’s easier to write code from scratch. Let’s dissect the marketing myths.

Myth 1: “No need to write code”

What they promise: the visual interface replaces programming. You connect nodes, configure fields, run. There’s logic, no code.

What actually happens: the logic doesn’t disappear, it’s just expressed in a more inconvenient form. Instead of functions — operators. Instead of variables — JSON paths you type into tiny fields and hope you guessed the correct nesting. Instead of a loop… And here’s where it gets interesting.

In the project I had to iterate over a list of destinations, at each step trigger a search for tours via the API and wait for results. level.travel’s API is asynchronous: you send a request, get an ID, then periodically query the status by that ID until the result arrives. Sounds like a normal task; you see this everywhere.

I couldn’t make this stable in n8n in two days. The loop would sometimes drop elements, sometimes crash without a clear error, sometimes return data in a format that broke the next node. There’s no proper debugging — you run the workflow, look at the outcome, guess where it broke, change something, run again. That’s not development; that’s divining in a JSON muck. With code, when something breaks — you have a stack trace, a line number, variables. In n8n you have a pretty diagram with green checkmarks on some nodes and a red cross on one — and absolutely no idea why exactly that one failed.

Myth 2: “Easy to prototype”

What they promise: even if you rewrite later, n8n lets you quickly test an idea. Sketch it in half a day, see if it works, iterate. Lower entry barrier, higher speed.

What actually happens: you can prototype quickly when you’re thinking about the problem, not the tool. n8n forces you to constantly think about itself — which nodes exist, how data is passed between them, why that field doesn’t map, what format the next block expects. That’s a separate skill, unrelated to solving the real problem.

A telling example: take an array, do something with each element, collect it back. In code it’s one line. In n8n — several nodes, each requiring several actions, and at every transition you must make sure the data arrived in the right format, nothing was lost and the structure didn’t go awry. Instead of thinking about the task, you’re thinking about how n8n transfers data between blocks. And it’s all clicks. Find a node — click. Open settings — click. Change one field — find it in the interface, click, type, close. Every little logic change turns into a series of mechanical mouse actions that have nothing to do with the problem you’re solving. After an hour it gets annoying. After two days — truly infuriating. And then you catch yourself wondering: why am I even doing this?

Because there’s an alternative, and it’s faster.

But the main point — the comparison baseline shifts. Before, the choice was between “n8n” and “write everything from scratch.” Now it’s between “n8n” and “ask an LLM to write the code.” I dropped the task into Claude, got a working Python draft in minutes, spent a couple of hours debugging and edge cases — and it was in production. That’s fast prototyping. Dragging nodes around the canvas while fighting JSON schemas is just slow, differently and with worse tools.

Myth 3: “Non-developers can use it”

What they promise: the visual interface is the whole point. An operations manager, marketer, or founder builds automations themselves without bothering a developer. It’s team scaling without hiring.

What actually happens: as soon as the task becomes a bit more than a linear “receive webhook → send to Slack”, you need someone who thinks like a developer. n8n doesn’t remove complexity — it hides it. A non-developer hits a wall, usually in production and at the worst possible moment — Friday evening when channels aren’t publishing and everyone has already left. After that, the developer gets involved anyway, only now they work inside a constrained visual environment without a proper editor, autocomplete, or decent version control.

Honestly, there is a scenario where it works: a simple linear workflow without loops and conditional logic — move data from one place to another. n8n handles that, and a non-developer can maintain it. The problem is that the same simple task is usually solved by a three-line script. And when the task gets complex, the illusion fades.

Myth 4: “Integrations are easy”

What they promise: hundreds of built-in connectors. Connect Slack, Google Sheets, Telegram, any popular SaaS — a few clicks. No HTTP clients, no API docs, just pick the service and configure.

What actually happens: for the happy path of built-in connectors — yes, quickly. Right up until you step outside that path.

level.travel required asynchronous polling: start a search, get an ID, poll until the result arrives. There’s no ready-made connector, so you build it manually. That’s a mini-loop inside the main loop over destinations — and that’s where n8n starts falling apart. Nested loops behave oddly, data starts getting lost or arriving in the wrong shape, the visual diagram becomes a spaghetti of wires, and you no longer understand what goes where.

Real APIs are always slightly imperfect. They have quirks, non-standard edge cases, pagination that doesn’t work how you expect, authorization with its own quirks. Code deals with this fine: write a helper function, call it where needed, move on. In n8n every non-standard behavior becomes another cluster of nodes, another field mapping, another point where it can quietly fail.

Myth 5: “The ecosystem has everything you need”

What they promise: n8n is a platform with a huge ecosystem. Whatever you want to do, there’s either a ready node or an integration. No need to pull in external libraries or untangle dependencies.

What actually happens: the ecosystem covers popular SaaS well — Slack, Notion, Google Sheets, Airtable, standard CRMs. Step aside — some industry API, niche service, or custom in-house system — and there’s no connector, you build it through the generic HTTP node. That’s code, just written into interface fields. As soon as the task goes beyond top-tier integrations, problems begin.

In the same project there was a task: take cheap flight data — origin city, destination city, route, price — and generate images for posts. Pretty images with a styled background, ready for Telegram. I honestly looked through n8n nodes for something suitable. There are AI-generation integrations — OpenAI, Gemini, Leonardo — but that’s image generation from a prompt, not inserting concrete data into a ready template. For that you need either paid third-party services or to cobble something via the HTTP node to an external API.

In Python this was solved in half an hour: an SVG template with pre-marked fields, insert the data, convert to PNG, send. Three clear steps, standard libraries, no external dependencies.

But then the next question arises: what if the client wants to change the template? That means storing the SVG file somewhere on the server so it can be updated. In n8n that means another separate workflow — to upload the file. Configure file transfer, ensure it saves to the right place, then pass its path to the main workflow. More threads, more nodes, more points where something can go wrong. What in normal code is solved with one line — “read the template from here” — in n8n becomes a separate infrastructure project.

Myth 6: “Logic is easy to reuse”

What they promise: you can break workflows into modules, call one from another, build reusable blocks. It’s visual programming, and it supports decomposition.

What actually happens: in code, when you see a repeating pattern — you refactor into a function and call it where needed. It takes a minute and then it works everywhere the same.

In n8n “extract to a function” means creating a separate sub-workflow. Then you must configure how arguments are passed — that’s a different mechanism with fields and mapping. Then make sure it runs without errors. Then configure how results are returned in the expected format. Then remember that if the sub-workflow changes, you must check all its callers. Each such “refactor” becomes a new cluster of nodes, new threads, new points of failure.

As a result, n8n developers more often copy logic between workflows than extract it to a common place — simply because it’s faster. That’s exactly what happened in our project: the clients quickly realized that the workflow for a new destination is easiest to create by copying a working one. Convenient until a bug is found. Or until the post template needs changing. Then it turns out there are already ten copies, and each must be found, opened, fixed manually, and tested. The classic “fixed in one place, forgot to fix in nine others.” And three months later, when you no longer remember how it all fits together, a real detective story begins — only instead of clues you have wires between nodes and no investigation log.

What happened in the end

After two days I deleted the workflows and wrote the logic in Python. Claude generated a working draft in minutes, a couple of hours of debugging — and the system worked.

What remained of n8n in this project? A thin wrapper: a schedule trigger, a call to a Python script, sending the result to Telegram. n8n as a fancy cron — that’s a perfectly valid use case.

All the real logic — asynchronous polling, iterating destinations, filtering, sorting, image generation, error handling — is in Python. Because that’s where it belongs.

When n8n actually makes sense

Simple linear workflows without nested logic: receive a webhook, write something, send it somewhere. Connect two well-supported services via their standard APIs. Create a quick trigger for a simple action.

If the workflow fits on one screen and has no loops — n8n will handle it, and it’s an honest tool for that job.

The problem isn’t the tool itself but the chasm between what it promises and what it can actually do. “Replace code with a visual interface” sounds convincing in a demo. In practice it means: replace readable, testable, debuggable code with a visual representation that’s harder to understand, harder to debug, and harder to maintain — especially when you’re not there.

If the task is simple — use n8n. If there’s real logic — write code. Or ask an LLM to write it for you. Either way it’ll be faster, and you’ll understand what’s happening in your system.