The notification came through at half ten on a Tuesday. TechCrunch headline, Zapier’s valuation, five billion and something, the automation space heating up, the future of work, all of that. I read two paragraphs and put my phone down because my terminal was open and the n8n container I had just restarted had brought the webhook endpoint back online pointing at localhost, which meant the Stripe payment confirmation flow I had spent four hours migrating from Make.com that afternoon was going to fire directly into nothing when the first real transaction came through.
That is the automation war as I have actually experienced it. Not the one in the headline.
I want to be fair to the framing because it is not entirely wrong. Zapier, Make.com, and n8n are genuinely competing for the same budget line in a lot of companies, and the money flowing into this space is real. But when you spend enough time inside these tools, building actual production workflows rather than demo scenarios, the competition looks less like a strategic battle and more like three different restaurants with different kitchen philosophies each claiming they serve the best food while you are standing at the pass trying to figure out why the order came out wrong.
Zapier is the one that charges you for the ingredients, the plates, the act of carrying the food, and the table it lands on. The task-based pricing sounds reasonable until you build anything with more than four steps and realise you are paying for every internal data pass, every lookup, every branch of an IF condition, including the branches that do not trigger. For simple automations that a non-technical user will maintain themselves, Zapier’s polish is worth something. For anything complex, you are eventually funding their Series E while your invoice climbs and your workflow still cannot handle a nested array without a workaround.
Make.com is more honest about complexity, and the visual canvas is genuinely good for the kind of multi-branch logic that would be a spaghetti mess in Zapier. I migrated a client out of Make mid-project last year and I will say clearly that the iterator module and the way Make handles data mapping across scenarios is genuinely well thought through. The problem is the error handling. When something breaks inside a complex Make scenario, the error message tells you a module failed and sometimes tells you which one, but the data that caused the failure is either truncated or completely absent from the log, and you end up running the scenario with synthetic test data and praying it reproduces the error. I have spent more hours than I want to count reconstructing the exact payload that caused a production failure in Make because the execution history simply did not keep it.
n8n keeps everything. The execution log shows you the input, the output, and the error at every node, and when something goes wrong in production you can click into the failed execution and see exactly what data the workflow received and where it stopped. That alone is worth a significant amount of friction.
And there is friction. I self-host on AWS EC2 with Docker Compose because the cloud pricing makes sense at the volume I am running, and the first few weeks of that setup taught me several things the documentation did not. The n8n docs tell you to set the WEBHOOK_URL environment variable to your domain. What they do not tell you, or did not tell you clearly when I was setting it up, is that if you are behind a reverse proxy and that variable is wrong, the webhooks will appear to register successfully in the interface, will show you a green URL, and will fail silently in production because the URL n8n is advertising to external services is still pointing at the internal container address. There is no warning. The workflow just never triggers and you spend two hours wondering if the external service is the problem before you check the actual webhook registration response and see localhost sitting there like it owns the place.
The fix is simple once you know it. Getting there without someone who had already made the mistake is not simple.
This is the gap that the market positioning language around all three of these tools actively papers over. The TechCrunch version of this space is about market share and enterprise contracts and AI integrations and the future of knowledge work. The actual version, the one that happens at half ten on a Tuesday while a payment workflow is pointing at localhost, is about whether the tool gives you enough visibility into what it is doing that you can fix it quickly when it breaks. Zapier does not. Make.com partially does. n8n does, but it expects you to have made the relevant mistakes already or to be willing to make them now.
What the headline valuation does not capture is that the real cost of an automation platform is not the subscription. It is the hours you spend debugging the gap between what the documentation describes and what the software actually does. On that measure, n8n is genuinely cheaper than the alternatives once you are past the initial self-hosting curve, because the execution log tells you the truth and the community has usually already hit the same wall and written about it.
The war is not between companies. It is between tools that respect your time and tools that make you feel like the problem is you.
Olaitan Oladipo holds a BSc in Sociology from Olabisi Onabanjo University. He is a self-taught automation builder who has spent years inside n8n doing the work that most tutorials skip: debugging OAuth errors at 2am, migrating client automations from Make.com mid-project, fighting reverse proxy misconfigurations on AWS EC2, and figuring out through trial and error what actually holds up in production versus what only looks clean in a demo.
He is not a developer by training and not a SaaS founder. He is the person in the Discord server who actually answers the question instead of linking to the docs.
His writing on n8n Automation Tutorial covers self-hosting, AI agent workflows, tool comparisons, and the security vulnerabilities the automation industry would rather not discuss. He has built AI-assisted invoice approval flows using OpenAI function calling, connected Claude via HTTP Request nodes, and holds considered opinions about Zapier, Make.com, LangChain, and CrewAI that their marketing teams would not appreciate.
He writes for people who are technical enough to follow a tutorial but experienced enough to want the honest version.