The Number That Matters Is Not 5.2 Billion
I was migrating a client off Zapier when the valuation news came through. Not the most dramatic timing, but appropriate. The migration had been on the roadmap for two months and had finally become urgent because the client’s Zapier bill for the previous quarter had crossed a threshold that made the finance team ask questions, and the answers to those questions, which involved explaining what a task was and why sending one email as part of a three-step Zap consumed three of them, did not land well. I was three workflows into the rebuild when someone posted the n8n funding round in the Discord.
Five point two billion dollars. I read it twice. Then I went back to the Merge node I was building to replace a Make.com aggregator that had no direct n8n equivalent, because the client had briefly used Make.com before Zapier, because the person who set up the original automations had made a different set of decisions under different pressures, and the whole stack was a stratigraphic record of tool choices that had each seemed reasonable at the time.
I want to explain what a $5.2 billion valuation for n8n actually means to someone who builds automations for clients, because the coverage of this story has mostly been written for people who invest in software companies, and the analysis that matters for the people reading this is different.
Zapier’s model is task-based billing. You pay per task, a task being approximately one action executed by one step in one Zap, and the pricing tiers are structured so that the number of tasks included in each tier sounds generous until you have a workflow with eight steps running on two thousand records a month, at which point the arithmetic stops being generous very quickly. I have had this conversation with every client I have moved off Zapier. The moment when the billing model becomes visible to someone who did not originally set up the account is always the same conversation. They say: we are paying this much per month and all it is doing is moving data between these three tools. And the answer is yes, and it has always been doing that, and the pricing was always going to end up here, it just took the workflow getting complex enough for the cost to become noticeable.
The reason Zapier built a task-based model is not because it is the most logical way to price workflow automation. It is because it creates a billing structure that scales with usage in a way that is extremely profitable when the customer’s workflows grow, and it was designed at a time when there was no serious self-hostable competitor that a non-developer could realistically operate. That time has been ending for a while. The n8n valuation is a data point about how far it has ended.
Here is the documentation failure I ran into during this particular migration that is relevant to the broader point. One of the Zapier workflows I was rebuilding used the Zapier built-in storage, which is a simple key-value store that Zapier provides as part of its platform for storing state between workflow runs. The n8n equivalent is the workflow’s static data, accessible through the Code node using the getWorkflowStaticData function. This is documented, but the documentation example shows a simple read and write without explaining that the static data object is not automatically persisted if the Code node throws an error partway through execution, which means if your workflow fails after reading state but before writing updated state, you can end up with a race condition where two subsequent executions both read the same initial state and both try to write different updates, and the second write wins without knowing the first one happened. I found this out because a deduplication workflow started letting duplicates through intermittently on high-volume days. The fix required restructuring the node order so the state write happened before the operation it was supposed to gate. None of this is in the docs. I found it by reading a GitHub issue from 2022 that had been closed as resolved when the static data feature was released, despite the edge case still existing.
Zapier does not have this problem because Zapier’s storage is managed by Zapier and the edge cases are their engineering problem. That is a real advantage, the same way Make.com’s visual scenario builder is a real advantage for people who think spatially about data flow and find n8n’s canvas approach harder to read. I am not making the argument that n8n is better for everyone. I am making the argument that the people who should be on n8n have been paying Zapier prices for Zapier convenience when they did not need Zapier’s convenience and were not getting full value from it.
The $5.2 billion number tells you that the investment community has decided this argument is correct. What it does not tell you is what happens to n8n’s pricing model when the company needs to justify that valuation to its investors in three years. A self-hosted open-source tool with a cloud offering is a specific commercial structure, and that structure has a history in enterprise software of slowly tilting toward the cloud offering as the self-hosted version becomes harder to keep current with.
I have moved enough clients between enough tools to know that the switching cost is always higher than the estimate. Move when the direction is clear, not when the pain is unbearable. The direction has been clear for a while. The valuation just made it louder.
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.