I use Gumloop for most of the automations I build now, mine and my clients’. It runs about $40 a month (dependent on how much volume you need). I’ve also started putting some of them in Val Town instead, which I’ll get to further down.
I get asked why constantly, because on the surface it looks like the same thing as Zapier or Make or n8n. A canvas, some boxes, arrows between them. And if you already know Zapier you’ll be productive in this thing in about ten minutes, so the pitch isn’t “it’s different.”
It’s one feature, and that’s the only reason I moved everything over to it.
First, the honest part
Gumloop does not have Zapier’s integration library. Not close. Zapier has thousands of prebuilt connections and that is their real moat.
So if you’re reading a comparison chart, Zapier wins. I’m not going to pretend that’s not a real tradeoff.
It just stopped mattering to me, and here’s why.
The feature: you can just build the integration yourself
Gumloop has custom nodes. A node is just one step in a workflow, the box on the canvas that does a thing.
With a custom node, you feed the tool the API documentation for whatever software you’re trying to connect to. Then you tell it two things: what you want to put in, and what you want to get out. It writes the code. You go back and forth on it for a bit, and then you’ve got a step you can drop into as many workflows as you want, forever.
Here’s one I actually built. I had a client on Avoma, which is a call recorder like Gong. Avoma’s HubSpot integration was extremely limited and it didn’t do the thing this client needed. Old me files a feature request and waits, or pays somebody to build something with the API.
Instead I fed the full API docs into the builder and told it: input is the HubSpot record ID, output is the transcript. Took about thirty minutes of troubleshooting and now that node exists and I can reuse it anywhere.
So I don’t need somebody else to have built the integration already. I just need the software to have docs.
I’m not a developer. I want to be really clear about that. It’s effectively vibe coding, and it works because the surface area is tiny. One step, known inputs, known outputs. The job is small enough that the risk of vibe-coding something in your operational process is extremely small.
Why not just let the AI talk to the tool directly
This is the question I get from people, especially people using AI a lot right now, and it’s a good one.
A lot of software now ships an MCP server, which is basically a standard way for an AI to call another tool’s functions. So why bother with a node? Just let Claude hit the MCP and do the thing.
Because of this:
“Each request that you make, it could potentially do a different action with the MCP if it translates it wrong. What their MCP nodes do is it will develop the actual code to do a repeatable action the exact same way every single time.”
When an AI reads your request live, every run is a fresh guess at what you meant, and ninety something percent of the time that’s fine. But if a workflow runs 400 times a month and it’s right 95 percent of the time, you’ve got twenty broken records a month that somebody has to go find and fix.
A node writes real code, so it does the same thing every run. The AI helped me build it once and then it’s out of the way. It’s not making a call while the thing is running. If you’re seeing other people talk about using AI to do something traditional automation could have solved, this is exactly that problem, and this is a solution somebody who isn’t in ops or development can use.
This is also why I won’t hand an LLM direct write access to a mature CRM portal. Those workflows are the company’s business logic, right? Read access is fine, ask it anything you want. But give it write access and people start skipping required fields, and now you’ve got a mess that takes weeks to clean up. Let the AI build the thing, then let the thing run on its own, and keep a person checking the output.
The money argument
Two of these, and they both come up on almost every call.
The $1,500 problem. I had a prospect a couple weeks ago looking at upgrading to HubSpot Professional, which starts around $1,500 a month, and she wanted it for one thing: access to workflows. I told her no and put her on a $40 a month Gumloop plan instead. I already wrote up how to avoid HubSpot costs when you’re early stage, so I won’t redo the math here.
The $3,000 problem. Different flavor. An agency I talked to was about to pay another agency three to five grand to build one custom integration. Fine, that’s a real option. But then every time something changes, they’re going back to that agency to fix it.
When you build it yourself, you own it. You can change it yourself. Even if someone builds it for you, it absolutely has to come with a handoff plan on how to run it yourself.
Same reason I don’t build client systems on proprietary tools that only work while I’m engaged. A lot of agencies do that and it really annoys me. Everything I build, you own.
The other tool I’m using now, Val Town
Gumloop isn’t the only place I build anymore. I’ve started testing Val Town for some of this and it’s a different kind of tool, so it’s worth explaining.
Val Town is a place to write a small script and have it live on the internet a second later. No server to set up, no deploy step. You write it, and it’s running at a URL. They call the scripts vals. A val can be a web address you can hit, a job that runs on a schedule, or something that fires when an email comes in. You also get a small database and file storage, so the script can remember things between runs.
The company describes its users as know-code engineers, as in not no-code. That’s their own wording and it’s accurate. It’s a code tool. No canvas, no boxes, no arrows.
How you use it if you can’t code
Same way I use custom nodes in Gumloop. I don’t write the code, I describe what I want.
Val Town has an AI built in called Townie that can read, write, and run your vals right in the editor. You can also point Claude Code or Cursor at it, because Val Town runs an MCP server, which is a standard way for an AI to work with another tool’s features. I’ve used Claude with it so far. Still very early stage in trying it but it seems like it’s going to serve a particular niche.
The reason this works for someone who isn’t a developer is the same reason the nodes work. The job is small and you can tell whether it ran. Ask for one script that hits one API on a schedule and writes the result somewhere. If it comes back wrong you can read the logs, tell the AI what happened, and it fixes it. Asking an AI to build you a whole app you can’t read is a much worse idea.
One thing to watch on the free plan. New vals on Free are public, so anybody can read your code. Don’t put proprietary info in there without paying. Pro is $21 a month right now and gets you private vals, plus the shortest schedule drops from 15 minutes to 1 minute.
Where Zapier still wins
If you need forty off-the-shelf connections to popular SaaS tools and nobody on your team is ever going to open an API doc, stay on Zapier. The library is the product and it’s a good product.
If your automations are simple triggers with no thinking step in them, you don’t need AI nodes, and you shouldn’t pay for them.
And if you’re already deep in n8n or Make and it’s working, you’re getting the majority of the functionality here already.
Where I’d start
Pick one workflow you wanted to build and didn’t, because the integration didn’t exist.
Then check if that software publishes API docs. If it does, you can probably get it done in an hour of trial and error if it’s your first time.
If you get one built (or run into a wall), set some time with me and tell me what it was, I’m always curious what people are stuck on.