n8n vs Make vs Custom Python: When to Stop Using No-Code Automation

Most “no-code vs code” arguments are sales pitches wearing a lab coat. This is not one.

I build automation for a living, and I reach for n8n, Make, and hand-written Python in roughly equal measure. The skill is not picking a favourite. It is knowing, on this specific job, which tool stops fighting you first.

Who This Is For

• Founders and ops leads deciding whether to standardise on Make, self-host n8n, or hire out custom code.
• Teams whose Make bill or Zapier task count is quietly climbing and want to know what “graduating” looks like.
• Developers who inherited a sprawling no-code workflow and suspect it should have been code.
• Anyone who has heard “just use code, it’s more powerful” and correctly suspects that is only half true.

If you want a pure code tutorial, my write-up on real-world Python automation workflows is the better door. This post is about the decision before that one.

The Three Options at a Glance

Three tools, three different centres of gravity.

• Make: hosted, visual, operations-priced. You draw scenarios; Make runs and scales them. Zero infrastructure, fast to a working result.
• n8n: open-source node-based workflows. Self-host it or use n8n Cloud. Visual like Make, but with real escape hatches: code nodes, custom nodes, and a flat cost curve when self-hosted.
• Custom Python: no canvas, no per-operation bill. Total control, total responsibility. You own the scheduling, retries, logging, and deployment yourself (or lean on an orchestrator).

Here is the honest scorecard. Read it as tendencies, not laws. Every row has exceptions.

Notice that no column is all wins. That is the whole point.

n8n

n8n is the pragmatist’s choice. It gives you a visual canvas and a trapdoor to real code, which is why it so often becomes the hybrid backbone I describe later.

Where it wins

• Flat cost when self-hosted. You pay for a small server, not per operation. At 50,000 executions a month this is the difference between a rounding error and a real invoice.
• Escape hatches everywhere. The Function and Code nodes let you drop into JavaScript (or Python, on recent versions) mid-workflow, so you rarely hit a hard wall.
• Low lock-in. Workflows export to JSON, the engine is yours, and you can move servers without begging a vendor.
• Decent error handling. Error workflows, retries, and per-node continue-on-fail give you more control than most hosted tools.

Where it bites

• You run it. Self-hosting means updates, backups, and the occasional 2 a.m. “why did the queue stall” investigation.
• Complex workflows get visually noisy. A 40-node canvas with nested branches is not obviously easier to reason about than 200 lines of tidy code.
• Versioning is partial. You can commit the JSON, but diffing a reordered node graph is nobody’s idea of a clean pull request.

n8n is where most teams should land before they consider full custom code. It buys you most of code’s flexibility without giving up the canvas.

Make

Make (formerly Integromat) is the most polished hosted experience of the three. If your job is “connect these fifteen SaaS tools and don’t make me think about servers,” it is hard to beat.

Where it wins

• Zero infrastructure. Nothing to host, patch, or monitor. That is a genuine, ongoing cost saving, not just a convenience.
• Fastest to a result. The scenario builder, huge app library, and instant execution logs get non-developers to a working automation in an afternoon.
• Great for the “glue” 80%. Form to CRM to Slack to spreadsheet: Make does this cleanly and reliably.

Where it bites

• The operations meter. Make bills per operation, and a busy scenario burns them fast. Cost scales with volume, and volume is exactly what successful automations produce.
• Branching and iteration get awkward. Once you are nesting routers, aggregators, and iterators to fake control flow, you are writing code in the worst possible IDE.
• Testing is manual. You run the scenario and watch. There is no unit test, no CI, no way to assert behaviour before it hits production.
• Lock-in is real. Your logic lives inside Make’s proprietary format. Leaving means rebuilding.

Make is not a beginner tool you outgrow and feel embarrassed about. For the glue layer it is often the right long-term answer. You outgrow it for specific workflows, not as a platform.

Custom Python

Code is the most powerful and the most demanding option. It has no ceiling on logic and no per-operation bill, but it also has no canvas, no free scheduler, and no one to call when it breaks.

Where it wins

• Unlimited logic. Complex branching, real data structures, external libraries, machine learning: none of it is a fight. It is just code.
• First-class testing and versioning. Unit tests, integration tests, code review, Git history, CI. This is the single biggest advantage over both no-code tools.
• Cost is just compute. No per-operation tax. Ten million records cost the same architecture as ten thousand.
• Best at data volume. Streaming, batching, and back-pressure are yours to control.

Where it bites

• Slowest to start, most to maintain. You build the scheduling, retries, logging, deploys, and alerting yourself, or adopt an orchestrator. My guide to scheduling and orchestrating workflows with Prefect exists precisely because raw scripts on cron do not scale.
• Invisible to non-developers. The ops lead cannot glance at a canvas and see what runs. That visibility loss is a real organisational cost.
• Easy to over-engineer. Not every three-step integration deserves a repo, a test suite, and a deploy pipeline.

The honest version: code wins where the logic is the hard part. Where the integrations are the hard part, no-code often wins. Most of my API-heavy work, like automating data workflows with APIs in Python, sits firmly in code because the transformations, not the connections, carry the difficulty.

The No-Code Ceiling

There is no alarm that goes off when you outgrow a tool. Instead you get symptoms. Any one is fine; three at once means you have hit the ceiling.

• You are hiding real logic in code nodes. If the interesting work already lives in Function nodes, you have a codebase with a confusing GUI wrapped around it.
• You cannot test before you ship. Every change is a live experiment because there is no way to assert behaviour first.
• Branching has become a maze. Routers inside iterators inside routers. You cannot hold the flow in your head.
• The bill scales with success. The more the automation works, the more it costs, and the curve is steep.
• You keep copy-pasting the same scenario. No functions, no reuse, so the same fragile flow is duplicated across five clients or five regions.
• Data volume causes timeouts. You are batching around execution limits instead of processing a stream.

flowchart TD
  A[Automation feels painful] --> B{Logic or glue?}
  B -->|Mostly glue| C[Stay no-code]
  B -->|Real logic| D{Can you test it?}
  D -->|No, and it matters| E[Graduate to code]
  D -->|Not critical| F{Cost scaling badly?}
  F -->|Yes| E
  F -->|No| C

A Decision Framework

When someone asks “which should we use,” I walk through five questions in order. Stop at the first that gives a clear answer.

1. Who maintains it? If non-developers must read and edit it, weight heavily toward Make or n8n. Visibility is a feature.
2. What is the volume? Low and steady favours Make (simplicity wins). High or spiky favours self-hosted n8n or code (flat cost wins).
3. Where is the difficulty? Connecting many SaaS tools = no-code. Transforming, deciding, or computing = code.
4. Does correctness need proof? If a silent failure costs real money, you need tests and version control. That pushes toward code, or n8n with disciplined code nodes.
5. How much lock-in can you accept? If portability matters, self-hosted n8n or code; if you happily trade it for zero ops, Make.

Here is the same logic as a tool-choice tree.

flowchart LR
  Start([New automation]) --> V{High volume<br/>or spiky?}
  V -->|No| M[Make]
  V -->|Yes| C{Complex logic<br/>or testing?}
  C -->|No| N[Self-hosted n8n]
  C -->|Yes| H{Non-devs<br/>maintain it?}
  H -->|Yes| Hybrid[n8n + Python worker]
  H -->|No| Py[Custom Python]

That “n8n + Python worker” box is the sweet spot more often than people expect. You let n8n own the trigger, the schedule, the retries, and the easy integrations, and you call a small Python service for the one genuinely hard node, then hand the result back. Visibility from the canvas, testability from the code.

flowchart LR
  T[Webhook trigger] --> N1[n8n: validate + enrich]
  N1 --> P[Python worker:<br/>the hard node]
  P --> N2[n8n: route + notify]
  N2 --> D[(Destination)]

To make the “hard node” concrete: imagine reconciling two order feeds with fuzzy matching and tolerance rules. In a no-code canvas this becomes a nest of routers and filters that nobody can safely change. In Python it is a function you can read, test, and trust.

def reconcile(order, candidates, tolerance=0.02):
    """Match an order to the closest candidate within a price tolerance.

    The kind of 'hard node' that turns a no-code canvas into
    an unmaintainable maze of routers — but is trivial in code.
    """
    best = None
    for c in candidates:
        if c["sku"] != order["sku"]:
            continue
        drift = abs(c["price"] - order["price"]) / order["price"]
        if drift <= tolerance and (best is None or drift < best[1]):
            best = (c, drift)

    if best is None:
        return {"status": "unmatched", "order_id": order["id"]}
    return {"status": "matched", "order_id": order["id"], "match": best[0]["id"]}

You can unit-test that in seconds. You cannot unit-test its router-maze equivalent at all, and that gap is the entire argument for graduating.

Failure Modes to Avoid

The wrong tool is only half the risk. These are the mistakes I see most, in both directions.

• Graduating too early. Rewriting a clean five-step Make scenario as a custom service because code “feels more professional.” You just traded a working automation for a maintenance burden.
• Graduating too late. Nursing a 60-node canvas with logic buried in code nodes for a year because migrating feels scary. You are already paying the cost of code with none of its benefits.
• Ignoring the operations meter until the invoice. Make’s per-operation pricing is fine until a successful automation 10x’s its volume. Model the cost at 10x before you commit.
• Self-hosting n8n with no backups or monitoring. “Flat cost” is not “free.” An unmonitored automation server is an outage waiting to happen.
• Rebuilding an orchestrator by hand. If your custom Python is sprouting a home-grown scheduler, retry queue, and dashboard, adopt a real orchestrator instead of reinventing one.
• Choosing on ideology. “We are a no-code shop” or “we only trust code” are not decisions. They are excuses to skip the five questions above.

Final Take

There is no winner here, and anyone who declares one is selling something.

Make wins the glue layer and the “no servers, please” mandate. n8n wins the middle: flat cost, low lock-in, and a trapdoor to code when you need it. Custom Python wins wherever the logic is the hard part and correctness has to be proven, not hoped for.

The senior move is not loyalty to a tool. It is recognising the symptoms of a ceiling, graduating one workflow at a time rather than rewriting everything, and being honest that a well-drawn Make scenario can outlive a badly-written codebase. Start no-code, stay no-code as long as it stops fighting you, and when it starts fighting back, reach for the hybrid pattern before you reach for a full rewrite.

If you are staring at a climbing bill or a canvas nobody dares touch, that is usually the graduation signal. Knowing which way to jump is exactly the kind of thing I help teams get right.