I'm not here to bury n8n. It did something genuinely valuable
for me: it taught me to think in flows. Trigger → fetch → transform → branch →
act — the visual canvas made that shape obvious in a way that staring at a blank
.py file never did. For a year it was how I prototyped every piece of automation
in my homelab.
Then I took the training wheels off. Most of what I built in n8n now runs as plain
code on a scheduler, and I ship faster, break less, and — the bit that surprised
me — I understand my own flows better than I did when they were drawn on a
screen. This is the honest arc: what n8n was brilliant for, the wall I hit, and
why "lean code" turned out to be the thing that finally made the flows legible.
What n8n was genuinely great at
Credit first, because it's real.
- It makes the shape of a flow visible. When you're new to automation, the hardest part is seeing the pipeline — where the data comes in, where it forks, where it acts. A node graph shows you that at a glance. It's the best teaching tool for "how does automation actually think" that I've used.
- The time-to-first-working-thing is tiny. Want to poll an API and post to Discord? Fifteen minutes, no boilerplate, no deploy. For proving an idea, that speed is worth a lot.
- The integrations are done for you. Auth, pagination, retries for a hundred services, pre-built. You wire boxes; you don't read a dozen API docs.
If you're learning, or prototyping, or you just want a small integration that'll
never grow — n8n is a great answer, and I still reach for it to sketch something.
None of what follows is "n8n is bad." It's "n8n is a great place to learn the
flow, and the wrong place to keep it once you understand it."
The wall: the theory was sound, the flows lied
My most expensive lesson came from a set of n8n workflows I trusted in production —
automation that reported success, cheerfully, for months, while doing essentially
nothing. The flows were right. The theory I'd learned on the canvas was sound.
But the canvas hid three things that plain code makes impossible to hide:
1. It painted itself green while failing. A node quietly set to "continue on
error," a success message a step later, and the graph glowed healthy while the
real work was rejected every single time. The visual told me a comforting story
the system couldn't back up. Nothing about a wall of green nodes forces the
question "but did it actually work?"
2. I couldn't diff it. A workflow is a big blob of JSON — boxes, wires,
positions. When something broke after a change, "what changed?" had no readable
answer. There's no meaningful code review of a canvas, no clean rollback, no
git blame on a wire someone re-dragged.
3. The logic hid inside the boxes. The graph shows you the shape of the flow,
but the actual behaviour — the expression in this field, the setting on that node,
the thing that only fires on a specific branch — is buried in dialog boxes you have
to click into one at a time. Ironically, the tool that made the high-level flow
visible made the details of the flow the least visible they've ever been. I
understood the diagram and not the system.
Why lean code made the flows clearer, not muddier
Here's the counterintuitive part. You'd expect ripping out the friendly visual
tool to make things harder to understand. The opposite happened, and it's the
whole reason for this post.
When the same flow is a Python script:
- The entire behaviour is on screen, top to bottom. Every fetch, every branch, every transform is right there in one readable file — no clicking into thirty nodes to reconstruct what actually happens. The flow I'd only seen the shape of on the canvas, I could now read in full.
- It fails loudly by default. An error is an exception, an exception is a non-zero exit, and a scheduler and a monitor can see that. Code doesn't paint itself green; it either exits 0 or it doesn't. The comforting lie isn't available.
- It lives in git. It diffs. It reviews. It rolls back. "What changed and when" is a real question with a real answer, and that alone has saved me more debugging time than the canvas ever saved me in setup time.
-
It runs on
cron/ a timer — no always-on engine. No separate service to keep alive, update, and back up just to fire a job once a day. A script and a scheduler line. Fewer moving parts is fewer things to be down.
The flow didn't get simpler. It got legible. I traded a picture of the flow for
the flow itself.
Ship faster? Yes — after the first one
The honest nuance on speed: n8n is faster to the first working version, no
contest. Lean code wins on everything after that — the tenth change, the
debugging session at 11pm, the "why did this fire twice" investigation, the
handoff to future-me who's forgotten how it works. Automation you actually rely on
spends 5% of its life being written and 95% being maintained, and the maintenance
is where the canvas taxed me and code pays me back.
So my rule now:
Prototype the flow in n8n if it helps you see it. Ship it as lean code the
moment you're going to depend on it.
The canvas is a whiteboard, not a factory. It's the best whiteboard I've used for
learning how automation thinks. But I don't run my production on a whiteboard, and
the day I stopped trying to was the day my automations stopped lying to me.
If you're where I was
- New to automation? Start in n8n. Genuinely. Build ten flows, feel the shape, learn to think trigger → transform → act. It's a superb teacher.
- Prototyping something throwaway or tiny? n8n, all day. Don't write boilerplate for a job that'll never grow.
- About to depend on it? Port it to plain code on a scheduler. You'll ship every change after the first one faster, you'll see failures instead of green lies, and — the part I didn't expect — you'll finally understand the flow you drew, because now you can read the whole thing at once.
n8n was my training wheels, and training wheels are not an insult — they're how you
learn to ride. But the goal was always to take them off and go faster. I did, and I
only wish I'd done it a couple of silently-failing months sooner.
Homelab notes from someone who learned to think in flows on a visual canvas, got
burned trusting one in production, and now prototypes on the whiteboard but ships
on plain Python and cron.
🤖 Drafted with AI assistance from my own homelab notes, logs and repos, then reviewed and edited before publishing.
Top comments (0)