n8n vs Claude Code: when you don't need a workflow tool anymore

n8n is a place where workflows live and run. A workflow waits for a trigger: a webhook, a schedule, a new file. Then it runs its nodes in order and logs every run. n8n's own page puts it this way: "n8n logs every execution, so you can re-run it from the exact point it failed." It hosts the workflow, schedules it and retries failed steps for you.

Claude Code is Anthropic's coding agent. You describe the job, it reads your code and writes more. It is included from the Claude Pro plan. When the task is done, it stops. n8n's comparison page says it plainly: "Claude Code has no persistent runtime by default."

So the fair comparison is n8n against a small app that Claude Code writes for you: a Next.js app on Vercel, a Supabase database, a few scheduled jobs and a log table. That app does what the workflow did. It also holds its own data and gives your team screens to work in.

The two also work together. Claude Code can build and deploy n8n workflows through n8n's MCP server, so a team that wants to stay on n8n can still let Claude do the clicking. If your team edits workflows every week and likes the canvas, that is a fair middle path.

The volume decides the n8n bill. A workflow that checks for new data every 5 minutes runs 288 times a day, about 8,640 times in a 30-day month. That is past Starter's 2,500 and inside Pro's 10,000. Add a second workflow on the same schedule and you are near the limit again.

A small app costs the same whether a job runs 100 times a month or 100,000 times, until the database or the functions get big. For a business app we use paid plans: Supabase Pro at $25 and one Vercel Pro seat at $20, so about $45 a month for hosting. The Claude plan is what you pay to change it.

The bigger cost is missing from every price page: the hours someone spends finding which node broke, and the hours to add a feature. That is where code got cheaper in 2026, because Claude Code writes and changes it.

Both of these are AI pipelines: a recording comes in, gets transcribed, a model scores it, the result lands in Supabase and a dashboard shows it. n8n is a good fit for that shape. Each call is one run, and the run log shows exactly which step failed for which call.

What these two have in common: one item in, one result out, a fixed order of steps, and no screens inside n8n itself. The dashboards are separate apps on Supabase. n8n is the conveyor belt between them.

Our own systems run the same way. Our outreach app drafts follow-ups on a 5-minute schedule and posts each one to Telegram. Our content hub schedules posts with Supabase pg_cron every 10 minutes. Both are Next.js and Supabase, written with Claude Code, with no workflow tool in between.

The file-size limit pushed us too. At Baltoro, a Chicago agency, a 70,000-row tender CSV crashed n8n and hung Make, so someone cleaned it by hand. A small pre-filter tool in code now cuts it to about 500 relevant tenders each time.

1. 1.The workflow needs its own data. You keep a Google Sheet or an Airtable base just so n8n has somewhere to store state.
2. 2.Several workflows share the same records. A rule change means editing three flows and hoping you found them all.
3. 3.People need a screen. Staff want to review, approve or correct what the workflow did. That screen is an app, so the workflow might as well live in it.
4. 4.The logic is a wall of IF nodes. Branches inside branches are easier to read, test and change as code.
5. 5.The files are big. Tens of thousands of rows, large archives, long transcripts in one go.
6. 6.The execution bill grows with every schedule. Polling every few minutes, per item, on several flows adds up.
7. 7.Nobody wants to touch it. The person who built it left, and the canvas is the only documentation.

One or two of these is normal. Four or more and the workflow is really a small product. It will be cheaper to run and change as one.

This is the path we use. It keeps n8n running until the new version has proven itself on real data.

1. 1.Export the workflow. n8n saves any workflow as a JSON file. Put it in a new repository with a short note on what it is for and who uses the result.
2. 2.Let Claude Code read it. Ask for a plain-language list of triggers, steps, credentials and outputs. Check it against what you know. This list becomes the spec.
3. 3.Move the data first. If the workflow writes to a sheet or a base, create the tables in Supabase and import the history.
4. 4.Write each trigger as a function. A webhook becomes an API route; a schedule becomes a cron job (Vercel cron for daily jobs, Supabase pg_cron for every few minutes).
5. 5.Add what n8n gave you for free. A runs table with start, end, status and error. A retry rule for calls to outside APIs. An alert to Slack, email or Telegram when a run fails.
6. 6.Run both side by side. Feed the same inputs to both for a week or two and compare outputs.
7. 7.Switch, then switch n8n off. Deactivate the old workflow, keep the export, and note the date.

A single workflow is a small job. A tangle of flows sharing data is a small app build; ours start from $1,990 with a working version in a week, in your accounts.

• The workflow works and nobody touches it. A stable flow that costs €20 a month is fine. Don't migrate it because a newer tool exists. Our dental pipeline stays on n8n for that reason.
• Your team edits the workflow itself. If an ops person changes steps every week and is happy in the canvas, n8n gives them that without a developer. Code gives that power to whoever reviews Claude's changes.
• It only moves data between two SaaS apps. "New form entry → CRM contact → Slack message" needs no database and no screen. A workflow tool is the shortest path.
• You need the run log for an audit, and nobody will build one. n8n's per-node history comes free. In code it's a table you have to design and keep.
• Nobody on your side can check a code change. Claude Code writes good code, but someone has to read the diff, test it and own the accounts. If that is nobody, hire a builder or stay on the tool.