A client sent me a screenshot of their SaaS expenses in February. Forty-two thousand dollars a year. Seventeen different subscriptions. The message underneath said: “I’ve been reading about what you do. How much of this can we get rid of?”
I looked at the list for about ten minutes before I replied. Not because I was uncertain, but because the honest answer was more complicated than the question.
The short answer was: probably eight to ten of those subscriptions, with enough time and the right architecture. The honest answer was: eight to ten of those subscriptions, plus a recurring cost that doesn’t show up as a line item but is just as real, which is the cost of someone like me keeping the replacement running when things change.
The stack doing most of the work in these replacements is not complicated to describe: n8n as the orchestration layer, Supabase or Airtable depending on the data requirements, SendGrid for transactional email, Cal.com for scheduling, and one or two LLM API calls for anything that requires judgment. Total infrastructure cost for a setup that replaces maybe twelve thousand dollars a year in SaaS subscriptions is somewhere around two hundred dollars a month, plus my time.
That last part is what the articles about this keep leaving out.
The first tool we replaced for this client was their lead scoring platform. Two hundred and eighty dollars a month for something that applied weighted rules to inbound leads and assigned priority tiers. I rebuilt it in n8n: a Webhook node catching the lead data from their form, a Code node applying their scoring logic, an HTTP Request to the OpenAI API for a soft judgment on lead quality based on the free-text fields, and a Set node writing the final score and tier to their Airtable base. Tested clean. Deployed. Saved them two hundred and eighty dollars a month.
Three weeks later the form provider changed how it named one of the fields in the webhook payload. The Code node stopped finding the field it was looking for, defaulted to zero on that dimension, and started misfiling leads. Nobody noticed for a week because the workflow kept running. Green execution logs. Wrong outputs.
The fix was four lines of code and a ten-minute diagnosis. But the ten minutes happened because I was monitoring the system. Before the replacement, the SaaS vendor was monitoring it.
This is the actual trade, and it’s a real one. When you replace a SaaS tool with an n8n workflow, you take on the operational responsibility for that function. The vendor’s engineering team was handling API compatibility, edge cases in the data, and upstream service changes. Now you are. If you have someone on your team who can do that, or you’re paying someone like me, the economics work well. If you’re assuming the workflow will run forever without attention, you’re going to have a bad month sometime in the next year.
The tools that replace cleanly are the ones where the logic is yours and the external surface area is small. Lead scoring, invoice processing, email sequences, internal reporting. All of these map well onto n8n workflows because the business logic lives in a Code node you control and the external dependencies are APIs with stable contracts. What doesn’t replace cleanly is anything with a complex UI that users interact with directly, anything with significant network effects, and anything where the value is in the data the vendor has accumulated rather than the workflow they’re running on it.
Make.com’s approach to this is worth mentioning, not as a compliment. Make’s marketplace of prebuilt scenario templates for common SaaS replacements looks useful until you try to modify one for your actual requirements, at which point you hit the ceiling of what Make’s module structure allows and start either paying for API calls you didn’t plan for or rebuilding in the HTTP module anyway. The templates are demos. The real work happens in the logic layer, and Make’s logic layer is weaker than n8n’s once you’re past the basics.
The documentation failure I ran into most often during these migrations was with the target APIs rather than n8n itself. The Airtable API documentation for its v2 endpoints had wrong field type specifications for three months after launch. I spent an afternoon building a record creation flow that kept returning a 422 with an error about field types, eventually opened the API explorer and sent a raw request manually, and discovered the docs had the data type for a linked record field wrong. The correct format was in a GitHub issue someone had filed, not in the official documentation.
That kind of thing happens on every migration. The SaaS tool you’re replacing handled it silently. The n8n workflow surfaces it as an explicit error, which is better for debugging and worse for your Tuesday afternoon.
The forty-two thousand dollar subscription list came down to about twenty-six thousand by the end of the project. Sixteen thousand in savings against roughly forty hours of my time to build and test the replacement workflows. That math works for the client. Whether it keeps working depends on how stable their vendor landscape stays and how much maintenance overhead grows over the next year.
The savings are real. The stack is real.
The missing line item in every article about this topic is the person who keeps it working.
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.