I built the same automation in n8n, Make, and Zapier. One died on the free tier.

Most "n8n vs Make vs Zapier" comparisons end at the pricing page. A screenshot of the plan tiers, a table of operations per month, maybe a line about which one has the most integrations. None of that tells you what happens when you actually run a real job through each tool.

So for EP02 I did the slow, honest version. I built the exact same automation three times, once per platform, with a stopwatch running on each. One of the three never finished. Not because I got the logic wrong. Because the platform would not let it run.

The job, and why it is a fair test

The task was deliberately plain: read a CSV from a URL, filter and transform the rows, write the results out. Nothing exotic. This is the kind of thing you reach for a no-code tool to avoid writing a script for. The important detail is that the transform needed a real code step. Not a "map field A to field B" click, but actual logic that runs for a moment before it produces output. That single requirement turned out to be the whole story. It is also the part these comparisons almost never stress, because a demo built entirely from pre-made nodes hides exactly the limit that bit me.

Zapier: dead at one second

Zapier's free tier caps a Code step at 1 second of runtime. My transform needed more than that. The step timed out before it did anything useful, and the job died on arrival.

Sit with that for a second, because it is the most useful thing in this whole build. It was not a bug I could fix. There was no logic error to debug, no loop to tighten back into range. The ceiling is the product.

On the free tier a Code step gets one second, and if your job needs two, the job does not run. You can write perfect code and still lose. That is a very different failure from "I made a mistake." It means the decision about whether Zapier can do your job was made before you opened the editor, and no amount of cleverness on your side changes it. If your automation leans on a real code step, this limit is the first thing to check, not the last.

Make: I abandoned it on camera

Make did not hit a hard runtime wall. It got stuck in the builder instead. Mid-scenario, wiring the same job together, the editor tangled badly enough that I could not make forward progress. I had a choice there. Cut around it in the edit and pretend I reached a clean finish, or leave the failure in. I left it in and abandoned the scenario on camera.

Faking a finish would have made the video smoother and the comparison useless. This is the cost that never shows up on a pricing page: time spent fighting the tool instead of building the automation. It does not fit in a feature table, and it is wildly uneven between platforms and between people. For this specific job, on this day, Make cost me the most of it and produced the least.

n8n: no runtime cap

n8n, self-hosted, ran the same job with no runtime cap. The code step took as long as it needed, and the automation finished. I want to be careful about what that does and does not prove, because "n8n wins" is exactly the kind of slogan I am trying not to sell you.

Self-hosted n8n has no runtime cap because you are the host. You are paying for it in a different currency: a server to run, updates to apply, and the reality that when it breaks at 2am, the on-call engineer is you. That is a real cost. It just is not a runtime ceiling, and for a job that lives or dies on a code step, that is the trade that mattered here.

What actually decides these comparisons

The takeaway is not a winner. It is where to look before you commit to one of these tools:

• Runtime limits on code steps. If your flow runs real logic, find the execution cap for your tier first. Zapier's free tier gives a Code step 1 second. That single number can decide the whole thing before you write a line.
• Per-operation billing. Platforms that meter by operation reward flows with few steps and punish loops. Count how your specific job maps to their billing unit, not their headline price.
• Time fighting the tool versus building the automation. The builder experience is a real cost even though nothing on the pricing page measures it. A tool you fight is expensive at any tier.
• Node library is not the differentiator you think. For a job built on a code step, the size of the integration catalog barely mattered. The runtime ceiling mattered more than every pre-made node combined.

The general lesson: these tools look interchangeable on a feature grid and behave nothing alike the moment you run one heavy job through each. The differentiator hides one layer below the pricing page, in the limits nobody advertises. The only way to find it is to build the same thing on all three and watch where it breaks.

The full build, all three versions of the job, and the stopwatch times are in the repo: github.com/Ships-Itself/builds/ep02-three-stopwatches. If you would rather watch the Make scenario fall apart in real time than read about it, the episode is on youtube.com/@shipsitself.