From Zapier to n8n: Why I'm Building an Automation Practice

The Bitbucket Pipeline That Broke Me

I'm dedicating a whole part of my company to automation workflows and AI. I've worked with people doing this stuff for years now, but I think the first time it really clicked for me was Zapier. I had a client, and I was struggling to build a Bitbucket pipeline. He threw together a Zapier automation, and it just worked.

This was years ago. Very rudimentary, early-form no-code automations. All I had to do was write a tiny bit of code and he thought I was a total wizard. But it was an interesting situation where Bitbucket Pipelines didn't have a great way to handle what we needed.

The project was a social site for gamers with Twitch integrations. Laravel PHP backend, and I'm pretty sure it was Vue.js on the front end because it was well integrated with the PHP, and being Laravel, it almost certainly was Vue. My role was setting up environments for the developers, which meant getting really hands-on with the codebase.

What we wanted was to use version control as a control plane for development environments. Your branch state mapped onto your environment. When you opened a pull request against the main or staging branch, it would launch everything. Your branch name dot your domain dot com, live, with a shared staging database. Yeah, schema changes could break the environment for everybody, but most of the time it was front-end changes or business logic changes. We were willing to tolerate the edge cases and handle those manually. Engineering beyond that was diminishing returns.

Now, all of this sounds like ridiculous overkill because of platforms like Vercel. And even back then, Heroku probably had something similar. But we had all of our infrastructure on AWS, and it wasn't worth migrating our entire system into someone else's ecosystem for one feature. Elastic Beanstalk was the AWS-native option, and I'm going to take a minute to bash it. It had rollbacks, it even had the preview environment feature, but man, what a clunky way to manage your infrastructure. I disapprove. Maybe I'll do a full Elastic Beanstalk breakdown someday, but for now just know: it's a nightmare. We weren't about to use it.

So Bitbucket Pipelines had a real nifty pull request opened trigger. The problem was pull request close had no such convenient trigger. We needed to tear down the environment when the PR closed, and there was no pipeline trigger for that. But there was a Bitbucket REST API that could do it. So the less technical founder reached out and said, "Hey, I've been doing a lot with Zapier. Can you maybe use something like this?"

I logged into his Zapier account, started playing around, hooked into the Bitbucket REST API, and within the hour I had it authenticated, sending requests, and I just had to write a few lines of code logic. He was blown away. When people use these no-code solutions, they're usually doing it because developers are expensive and they just want pre-built nodes they can drag and drop and duct tape together. Some people basically build what is a SaaS backend out of no-code automations. It looks like spaghetti, but it works. No one had to write a single line of code, and it does more than a lot of people's SaaS products. More power to you.

How Vercel Automated the Automation Away

It's worth stating how much Next.js and Vercel have changed the landscape of full stack and DevOps. Back then, if you had a Laravel app, anything PHP, Nginx, Apache, a LAMP stack, you had to get really hands-on with the codebase just to stand up an environment. It's weird to think how Next.js just works with Vercel.

There's a lot of power in having your deployment solution and environment management solution that closely integrated. The team that developed the Next.js framework is the team that maintains the Vercel platform. That's an important forcing function. The people developing the framework your stack depends on are also responsible for maintaining what is basically the control plane of your infrastructure. This is what you'd call platform as a service.

And it has real security implications too. As soon as a major vulnerability is discovered in a version of Node.js, day one, by end of day, they've alerted everyone. It scans everyone's Node version because it's in charge of deploying it.

This is one way where automation got automated away. The scenario I just described, where we had to roll our own Zapier-plus-Bitbucket-API hack to tear down environments? Vercel does this as a default feature. Every time you open a pull request with a branch connected to Vercel, it launches a preview environment. When you merge, it tears down. Fully automated. Don't use PHP. Don't try to set up your own Bitbucket pipeline. Just use Next.js and Vercel until your product grows to the point where the projected cost savings of self-hosted AWS infrastructure justifies the engineering cost of setting it up. You're probably not going to get there anytime soon. You may never get there. You may run a thriving business that just loves it some Supabase, loves its Vercel, and you never have to hire a DevOps engineer to automate your deployments.

The People I'm Building This For

The market I'm targeting with automation solutions is a specific kind of person. Someone who has a dream, an idea they want to execute on, and they've been grinding on it. Limited budget. Bootstrapping the whole thing. Learning to build a lot of it themselves. They don't identify as technical, but they're so dedicated to their business goals that they find they can learn a lot about tech if they just try. They quit believing they can't, believe that they can, and they wind up gaining a pretty decent proficiency.

But there's such a learning curve to coding if you're going to do it right. And there are so many bullshitters who learn just enough about programming to convince would-be startup founders that they're legit developers. It's kind of an outrun-the-bear situation. I don't have to outrun the bear, I just have to outrun you. There are a lot of those out there. So you've got an environment with a lot of incentive to try to do as much as you can yourself, and these no-code tools sprung up to help people do an end run around a developer altogether.

The people who use these solutions aren't looking at them as an end game. These products solve a much deeper problem: how do we build a company without spending hundreds of thousands of dollars on programmers? That was a major viable thing to emerge that gave you hope. And now AI is doing the same thing, just in a different way. That's why there's a lot of talk about Claude Code being the n8n killer.

Why I'm Learning n8n (and Why I'm Not Becoming "The n8n Guy")

My plan is not to become an n8n wizard and throw out my whole career in full stack development, DevOps engineering, and cloud architecture. That's not a wise plan. I've got a couple of takes on this.

One, I predict that n8n is going to get with the times and evolve. You can already see chatbots springing up to help walk people through things. I think you're going to see more reliable and advanced AI chatbots that will build custom nodes on the fly. I get a sense that n8n is here to stay.

Two, there's a huge market of people who have already built really complex solutions with n8n automations, and some of them are so complex that they need a technical expert to help them transition away from their spaghetti nodes. It's great that that rhymes with spaghetti code, because that's an old term in development circles. We've been writing spaghetti code for decades. We're not surprised you built spaghetti nodes in n8n. And you might pay thousands of dollars to developers to replace your n8n workflows with code, but what they've done is replace your spaghetti nodes with spaghetti code. If you're going to write bad architecture, you might as well do it cheap.

So there are two classes of client I'm targeting. The first is someone who already sees n8n as a trusted, viable solution. They might have a prejudice that anyone who doesn't know certain fundamentals about n8n isn't worth their time. I could pull the snobby elitist card and say I'm too good for n8n because I know TypeScript and Python. I don't want to do that. I want to be able to say: yes, I know n8n. Yes, I can do things in n8n. Here's an example of something awesome I still have running in it. But n8n as we know it traditionally isn't the future. Let me show you what the future is. If I don't have experience in the platform, it sounds like sour grapes.

The second class is someone who has already built a lot in n8n. Regardless of whether or not it's the future, they need me to understand how their system works right now if I'm going to clean it up and replace it with better architecture. You need to be able to drive the thing if you want to park it. You need to be able to reverse engineer the thing if you're going to engineer something better.

Refactoring Nodes Like Refactoring Code

My technical strategy right now: I'm learning custom nodes and workflow management. I've got a Next.js app because I can deploy it to Vercel, my IDEs have a lot of nifty rules documents and MCP tools for Next.js codebases, and Next.js is well fitted for what I'm building. Full stack application with a Supabase backend, and I'm using my own website as the first example.

I've got two processes I'm automating that are actually very common problems. One is lead capture. I've got lead capture forms on my landing site that feed into a Supabase leads table with a scoring table. The other is transcripts. I record voice memos while I'm driving, trying to regain lost time by finding productive things I can do in the car. I generate a transcript from the memo, and that transcript needs to be processed into a blog article. Each step in the transcription process is an AI agent I need to build. Step one is cleanup: fixing spelling errors, correcting technology names. LLMs are really good at using the context of the whole transcript to make spelling corrections, especially with tech terms. The transcriber is going to absolutely butcher "n8n" every single time, but the LLM knows exactly what I'm talking about and goes back to fix it everywhere.

What I'm doing is intentionally slowing down my n8n workflow process, but for a specific purpose. I want all of my workflow configurations in JSON, and I want all of my custom nodes in actual code. Anytime I need to improve on what a node is doing, I want to be able to use Claude Code or Cursor to generate a custom node that trims out the fat, combines several steps, and cleans up the spaghetti. I want to be able to look at a client's big nasty mess of spaghetti nodes and come back an hour later with something they can actually understand. You had a hundred nodes all over the place and I got it down to a dozen.

It's the same thing as refactoring code. I want to refactor nodes. You've got these three nodes you always stick together? Why not build one custom node with the functionality of all of them? "Well, that would take all day or a week of development." I want to get to where I can do it in minutes, between me and Cursor and Claude Code and my own curated library of custom nodes.

And then once I get all of a client's node architecture into code, I can have a conversation with Claude and say: we've got all these nodes, build us a SaaS product that does this exact thing without n8n. Within minutes we should be able to generate actual architecture. There's another benefit too. A lot of people have really sophisticated, novel solutions that they might be able to protect legally as IP. But because it's just a bunch of nodes in n8n, what are you even protecting? If I can version control all of your workflow configs in JSON and all of your custom node code, the actual TypeScript, that's IP. It's the novel part of your product, in code. That has legal implications.