Is it genuinely no code, or low code with better marketing?

For the common shapes it is genuinely none, and at the edges nearly every platform offers a way to drop code in. That is a feature rather than a broken promise, because the alternative is a hard ceiling with nothing beyond it. The useful question when comparing is where each one puts that hatch and who on your team can reach it.

When should we stop and write code instead?

When the flow has become harder to read as boxes than it would be as text, which usually arrives with deep branching rather than with length. A long straight sequence stays legible on a canvas indefinitely; a heavily conditional one does not. Several platforms say this themselves on their own pages, which is a good sign rather than a warning.

Does it still need someone technical?

Less often for the building and roughly as often for everything around it. Somebody has to decide what happens when a step fails, hold the credentials, notice when a connected system changes its behaviour, and own the thing when it breaks at an inconvenient time. Those responsibilities do not disappear because the construction got easier.

What decides the cost?

Volume against the billing shape, almost always before capability enters the conversation. Per-task pricing is the quickest route to something working and climbs steeply with use, credit-based pricing is cheaper at scale and still compounds, and self-hosting converts the bill into operational effort. Model the arithmetic at the volume you expect rather than the volume you have.

Glossary

No code

No code describes tools where the work is assembled visually instead of written in a programming language, so the people who understand the process can build and change it without waiting for somebody who writes software.

In plain terms

Building something by dragging pieces around instead of typing instructions a computer runs. The point is not that it is easier for everyone, because it is not, but that the person who understands the job can do it themselves rather than describing it to somebody else and waiting. That shortened loop is usually worth more than the hours saved on the building itself.

Why it matters

Because the bottleneck it removes is rarely the one people name. Teams describe the benefit as speed, and what actually changes is who is allowed to make a change: the person who knows the process stops filing a request and starts editing the thing directly. The compounding gain is the small corrections nobody would have raised a ticket for.

How it works

The assembly is visual and the logic is still logic. Dragging steps onto a canvas removes the syntax and none of the thinking, so branching, error handling and the awkward cases where two systems disagree about a date format all still have to be reasoned about. What has gone is the typing and the setup, which is a real saving and a smaller one than the marketing implies.

Every serious platform keeps an escape hatch, and where it sits is the honest comparison. Some let you drop real code into a step when the logic demands it, some expose the underlying project so an engineer can take it further, and some deliberately keep everything behind their own layer so nothing needs configuring. None of these is wrong, and choosing without noticing which one you have picked is how teams get stuck.

The visual version stops being simpler at a threshold that arrives sooner than expected. A flow with a handful of steps reads beautifully on a canvas, and a deeply branching one becomes harder to follow as boxes and arrows than it would be as code, which is the point at which the tool's own pages start recommending you graduate. Recognising that moment is worth more than avoiding it.

Pricing shape decides where the ceiling falls, more than capability does. Per-task billing is the fastest way to something working and gets expensive as volume climbs, credit-based billing undercuts it at scale and still compounds, and running the platform on your own infrastructure trades the bill for operational effort somebody has to own. Teams usually meet the ceiling before they meet a feature they cannot build.

The same phrase now covers a second, newer thing: building whole applications from a description. Those tools generate a working front end, a database and authentication from plain language, and the split among them is whether you get code you own or a bundled backend you cannot see. That is the same escape-hatch question in a different costume.

Where each platform keeps its escape hatch

Laying the category out by its escape hatch rather than by its feature list is what makes the choice legible, because the features converge and the hatches do not. Every platform here will connect your applications and run a job on a schedule, so a comparison table of capabilities mostly produces ticks in both columns and tells a buyer very little. What differs, and what decides how the arrangement ends, is what happens on the day the tool cannot do the next thing. At the left-hand end that day is a wall, and the answer is to rebuild elsewhere. At the right-hand end it was never a wall at all, and the cost of that was paid up front in operational effort nobody enjoys. Neither end is the correct answer, and picking without knowing which one you have picked is what turns a good year into an expensive migration.

Seen in the wild

A platform whose breadth is the point, connecting a very long tail of applications through trigger-and-action steps that need no code at all.
Zapier
A visual canvas where branching, loops and data transformation are first-class, and which accepts real code in a step when the logic demands it.
Make
An app builder that keeps the database, authentication and hosting behind its own layer, so a non-technical builder never configures a server.
Base44

Common misconceptions

People assume

It means anyone can build anything.

In fact

It means anyone can build the shape the tool anticipated, which is a large and genuinely useful set that has edges. The syntax has gone and the reasoning has not, so somebody still has to think about what happens when a step fails or two systems disagree. The skill that transfers is process design rather than programming.

People assume

The saving is the time spent building.

In fact

The saving is mostly the waiting, which is a bigger number and a less visible one. Building a flow might take an afternoon either way; the difference is that the person who understands the process does it now instead of describing it to somebody else and joining a queue. Small corrections that were never worth a ticket are where the compounding happens.

People assume

Choosing one is a capability decision.

In fact

It is usually a pricing-shape decision, because teams meet the billing ceiling long before they meet something they cannot build. Per-task, per-credit and self-hosted arrangements diverge sharply at volume, so the arithmetic at the scale you expect to reach tells you more than a feature comparison does.

Telling them apart

No code vs Automation

No code

How the thing gets built: assembled, not written.

Automation

What the thing does: work that runs without a person.

One is a construction method and the other is an outcome, so plenty of automation is written in code and plenty of visual building produces things that are not automation at all.

Questions

Is it genuinely no code, or low code with better marketing?: For the common shapes it is genuinely none, and at the edges nearly every platform offers a way to drop code in. That is a feature rather than a broken promise, because the alternative is a hard ceiling with nothing beyond it. The useful question when comparing is where each one puts that hatch and who on your team can reach it.
When should we stop and write code instead?: When the flow has become harder to read as boxes than it would be as text, which usually arrives with deep branching rather than with length. A long straight sequence stays legible on a canvas indefinitely; a heavily conditional one does not. Several platforms say this themselves on their own pages, which is a good sign rather than a warning.
Does it still need someone technical?: Less often for the building and roughly as often for everything around it. Somebody has to decide what happens when a step fails, hold the credentials, notice when a connected system changes its behaviour, and own the thing when it breaks at an inconvenient time. Those responsibilities do not disappear because the construction got easier.
What decides the cost?: Volume against the billing shape, almost always before capability enters the conversation. Per-task pricing is the quickest route to something working and climbs steeply with use, credit-based pricing is cheaper at scale and still compounds, and self-hosting converts the bill into operational effort. Model the arithmetic at the volume you expect rather than the volume you have.

Key takeaways

The syntax goes; the reasoning about failure and edge cases stays.
Every serious platform has an escape hatch, and where it sits is the real comparison.
The gain is mostly the waiting removed, not the building time saved.
Deep branching, not length, is what makes a canvas harder to read than code.
Teams hit the pricing ceiling long before they hit a capability ceiling.