The internet loves a fight between no-code and code. In practice nobody who builds automation for a living is on either side. The useful question is not "which is better?" but "which is right for this piece of this system?"
The three approaches
- No-code: you assemble the automation visually, from ready-made blocks, with no programming. Zapier is the classic example.
- Low-code: mostly visual, but with the option to drop into code where the blocks run out. Make.com and n8n both sit here, n8n leaning further toward code.
- Custom code: you write the system in a programming language such as JavaScript or Python and run it on your own infrastructure.
No-code: where it shines
- Speed. A working automation in an afternoon, with nothing to install or host.
- Accessibility. The person who understands the process can build it themselves.
- Visibility. You can see the flow, which helps colleagues understand and trust it.
- Maintenance by non-programmers. A small team can keep it running.
The limits: pricing that scales with usage, constrained logic, dependence on the platform's available integrations, and difficulty debugging once flows get large.
Low-code: the practical middle
This is where most of my client work lives. The visual canvas does the plumbing, such as triggers, connections and routing, and a small amount of code handles the awkward parts: reshaping data, calling an unusual API, applying a custom rule.
- You rarely hit a hard wall, because code is available when you need it.
- Most of the system stays readable to non-programmers.
- You can often self-host, which changes the cost picture, as discussed in n8n self-hosting.
The trade-off is a steeper learning curve than pure no-code, and the discipline to keep the code small and the flow readable.
Custom code: when it earns it
Writing a system from scratch is justified when:
- It is core to your product, not an internal convenience.
- Volume or performance demands it, and platform fees would be punishing.
- The logic is complex, with many conditions that are painful to draw as a flowchart.
- You need tight control over security, data handling or deployment.
- You have people to maintain it, and tests, documentation and a deployment process.
The hidden cost is everything around the code: hosting, monitoring, updates, security patches, and a developer who understands it six months later. A script nobody can maintain is a liability.
Side by side
| No-code | Low-code | Custom code | |
|---|---|---|---|
| Time to first version | Hours | Days | Weeks |
| Skills needed | Process knowledge | Process plus light coding | Software engineering |
| Flexibility | Limited | High | Unlimited |
| Cost at high volume | Can be high | Moderate, or low if self-hosted | Lowest running cost |
| Who can maintain it | Almost anyone | A technical person, mostly | A developer |
| Visibility of the logic | High | Good | Only to those who read code |
| Lock-in | High | Medium | Low |
Why the best systems mix them
Real systems have parts that suit different approaches. A typical one I build:
- The plumbing, triggers, notifications and data movement, in a visual platform where it is easy to see and change.
- A small code step for the one piece of logic the blocks cannot express.
- A database for state.
- An AI step for the part that involves language.
- Occasionally a separate small service for something heavy or unusual.
This is the same hybrid thinking as in AI agents vs AI automation: use the simplest thing that is reliable for each part, and add power only where it is needed.
How to decide
- Who will maintain it? If it is a non-technical team, favour visual tools.
- How many times will it run? High volume pushes toward self-hosting or code.
- How unusual is the logic? Standard flows suit blocks. Strange ones need code.
- How long must it last? A quick internal helper and a core business system have different standards.
- What is the cost of failure? High stakes call for testing, monitoring and review, whatever you build with.
- Start visual and add code when you hit the wall, not the other way round.
If you are choosing a platform to start with, n8n vs Make vs Zapier compares the main options, the AI tool stack every business should know covers the surrounding tools, and how to become an AI automation engineer shows how the skills build up if you want to take the work on yourself.
Pick the approach that matches who will look after the system, not the one that is fashionable. The most successful automations I have seen were built with whatever the team could confidently maintain, and were still running years later.