The migration was supposed to take a week. It took three, and the middle one I would prefer to forget entirely.
The client had seventeen active scenarios in Make.com. Not complicated ones by Make standards, mostly CRM syncs, a few form-to-spreadsheet flows, one moderately ambitious one that parsed webhook payloads from their e-commerce platform and conditionally updated two different systems depending on order value and SKU category. I had done Make-to-n8n migrations before. I told them a week. I was wrong in the specific way you are wrong when you underestimate not the complexity of the work but the number of places where two tools that appear equivalent turn out to handle the same problem with completely different assumptions.
Make.com’s router module is the clearest example. In Make, a router is a visual branch point where you draw paths and attach filters. It is clean, it is obvious, and the UI makes the logic feel spatial in a way that non-technical clients can follow in a screen share. When I rebuilt those same branches in n8n using IF nodes and Switch nodes, the logic was identical but the canvas looked like something had exploded. Not because n8n was wrong. Because n8n makes you see the actual structure of what you built instead of dressing it up. That is genuinely a difference in philosophy, not just aesthetics, and depending on who is reading the workflow it matters.
But here is where Make started losing the argument. That e-commerce flow, the one parsing order webhooks, needed to handle a case where the payload structure changed depending on whether the order came from the web app or the mobile client. Same endpoint, different JSON shapes. In Make, I had this working with a series of nested filters and a get-variable workaround that I had found in a forum post from 2021 that was written for an earlier version of the module. It worked until it did not, which is the worst category of working. In n8n I put a Code node at the top of the flow, wrote a normalisation function that handled both shapes and output a consistent object, and from that point forward every downstream node saw the same data regardless of source. Twenty lines of JavaScript and the problem was architecturally gone rather than filtered around.
That is what people mean when they say n8n scales better with complexity. They do not mean it handles more volume. They mean that when your logic gets weird, n8n lets you write your way out of it rather than trying to configure your way out of it, and those are different things.
I want to say something about Zapier that Zapier would not enjoy reading. Zapier is not a bad product. It is an extremely polished product that has correctly identified its market, which is people who want automation to work without thinking about it, and it serves that market well. The problem is the pricing, which is structured as though the goal is to make sure that any automation complex enough to be genuinely useful costs enough that you have to justify it quarterly. I have watched clients pay Zapier invoices for workflows that were running ten thousand tasks a month and producing maybe two hours of saved time, and the math did not work. When I moved those clients to n8n on a shared EC2 instance the automation became invisible in their costs, which is where automation should be. Zapier’s pricing makes automation visible in your costs, which is the wrong outcome.
Make.com understood this and undercut Zapier on operations pricing, which is why it grew as fast as it did. But Make made its own bet, which was that a better UI and cheaper operations would be enough, and I think that bet is now under pressure in a way that was not obvious two years ago. The clients I work with who started on Make are not leaving because of price. They are leaving because they hit the ceiling of what Make’s visual paradigm can express, and they do not want to hire a developer to work around it. They want to stay inside their automation tool and write a function when they need to. Make does not really let you do that. n8n does.
The documentation situation on n8n is real and I am not going to pretend otherwise. There are nodes where the documented parameters do not match what the node actually accepts. There are credential configuration pages that describe a flow which has since changed in the UI. I spent an afternoon last month trying to get a specific HTTP Request node to handle digest authentication because the documentation said it supported it and the node kept returning 401s. It does support it. The field label in the UI had changed and the documentation had not caught up. I found the correct field by opening the node source on GitHub. That is not a workflow, that is archaeology, and it happens often enough that I now treat the n8n docs as a starting point rather than an answer.
The community fills the gap, which is both a testament to how many people are actually using this thing seriously and a mild indictment of the documentation process. The Discord is genuinely useful. The forum has solutions to problems that predate the solutions being in the docs by sometimes six months. You learn to triangulate.
Make.com was supposed to kill Zapier by being cheaper and more visual. It mostly succeeded on the cheap part. n8n is killing both of them by being the tool you reach for when the automation actually matters, when it runs on your infrastructure, when the data cannot leave your environment, when the logic is too strange to configure and needs to be written. That use case is not niche. It is just not the use case that makes a good homepage.
The future of automation tooling is not prettier drag-and-drop. It is code-optional workflow engines that treat self-hosting as a feature rather than an edge case.
n8n is the only one of the three that actually believes that.
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.
