Why I Reach for Code When Everyone Else Reaches for Zapier

There's a piece of received wisdom about automation that I keep bumping into, and I think it's mostly wrong.

It goes like this. If you're a small business and you want to automate some fiddly bit of admin, the sensible move is a no-code tool. Zapier, Make, that sort of thing. You drag a few boxes around, connect your apps, and away you go. No developer needed. And crucially, you own it. You can change it whenever you like.

I tend to build things in code instead. For a long time I half-assumed that made me the awkward one, the developer reaching for a hammer because hammers are what he owns. But the more jobs I do, the more I think the standard advice has it backwards for the kind of business I usually work with.

Let me explain why.

The bit nobody admits

The big selling point of a no-code tool is that you own it and you can tweak it yourself. No being held hostage by a developer.

It's a lovely idea. It's also, for most small businesses, completely theoretical.

Be honest about how this actually goes. You build the first version with someone, or you watch them build it. It works. And then you never open it again. You're busy. You're running a business. Poking around inside an automation to adjust a step is not your job, and it never will be. That's fine. It shouldn't be.

So the "you can change it yourself" benefit, the one thing that's meant to make no-code the safe choice, quietly evaporates for nearly everyone. You're not going to maintain a Make flow any more than you'd maintain a script. Once you accept that, the whole comparison changes.

The real question

If you're not going to maintain either option, then "which one can I tweak myself" stops mattering. The questions that actually count are these:

• How many things can break?
• How quietly do they break?
• Who can fix it when they do?

On all three, a no-code tool tends to come off worse than people expect.

A typical Zap or Make flow has a lot of moving parts, and most of them sit outside your control. An app updates its connection and a step stops working. An auth token expires. A webhook changes. You hit a rate limit. The vendor quietly caps your task allowance unless you move up a pricing tier. Each of those is a seam, and each seam is a place things can fail without anyone noticing. You find out when the invoices stop going out, not before.

A bit of code doing the same job has fewer joints. No monthly task ceiling. No vendor changing the rules underneath you next quarter. And when it does break, it breaks in a way someone can actually read and fix, rather than something you have to poke at through a menu in somebody else's software.

I wrote a while back about a Python script that sorted out a recurring invoice headache of mine. That's a fair example. It's small, it's boring, it does one job, and it has carried on doing that job without complaint or a subscription fee. It's saved me hours and hours of mundane work, the sort of thing you don't even notice eating your week until something takes it off your plate.

It's not really about lock-in

People reach for the word "lock-in" here, usually aimed at the developer. Don't tie yourself to one person, they say.

But both options tie you to someone. A no-code flow ties you to a vendor, their pricing, their roadmap and their decisions. A bespoke build ties you to whoever maintains it. The difference is who you're depending on. A vendor on the other side of the world owes you nothing and can change the deal whenever it suits them. An agency you chose, and can pick up the phone to, is a relationship you actually control.

That's not the same kind of dependency at all.

When no-code is the right answer

I'm not anti no-code. I use these tools when they fit, and sometimes they're clearly the better call.

If you need something stitched together across a dozen different services in a hurry, a no-code tool will get you there far faster than a custom build. And if the value is in glueing together a load of apps that are a pain to talk to directly, that's exactly what these platforms are good at. Speed to a first working version is a genuine strength, and worth paying for when speed is the thing you need.

That's a real category of work. It's just not most of what lands on my desk.

So which should you use?

Most of the time the honest answer is that it depends on who's going to live with it, and how much it costs you when it stops working at the wrong moment.

If you've got a process that keeps eating your team's time and you're not sure which way to jump, get in touch. Happy to take a look and tell you straight which one actually fits, even if the answer turns out to be the cheap one.