Why I replaced my no code automations with scripts and a local model
# Why I replaced my no code automations with scripts and a local model
A while back I sat down and added up what the small automation tools were costing me each month. The big subscriptions I already knew about. These were the little ones: the drag and drop service shuffling data between apps, the tool sorting my incoming mail, the one tagging things and filing them away. Each was cheap on its own. Together they made a real bill that arrived every month, forever, and the money turned out to be the lesser problem. Dozens of small automations were living inside other people's websites, each able to break in ways I could neither see nor fix.
So I moved the ones that mattered onto small scripts and a local AI model running on my own machine. The migration went well. It was also slower and lumpier than the tidy version of this story would claim, so here is the honest accounting, including the parts where the old way was better.
No code tools deserve a fair hearing
I built my entire early setup on one of these visual tools and it carried real weight for over a year, so I want to be fair to where I started. You click two apps together, draw an arrow from a trigger to an action, and a thing that used to need a programmer just works ten minutes later. For simple jobs, when this happens do that, they are close to perfect, and I still recommend them to anyone starting out.
If all you need is a new signup dropping a row into a spreadsheet, stop reading and go use one.
Outgrowing one of these tools is also a compliment to the tool. It let me start before I knew what I was doing, and by the time I left, it had taught me exactly what my automations should look like. Nobody should start with the setup I am about to describe. You start simple, learn what you actually want, and only then does a custom rebuild make sense. Building the complicated version first is how people lose months to a system nobody needed.
Where it started to hurt
Three pains crept up on me slowly.
Cost came first. These tools charge by the task, and as my automations multiplied and ran more often, the bill climbed in a way that had nothing to do with the value any single one produced.
The ceiling came second. The moment I wanted something slightly clever, something the visual editor had no neat box for, I hit a wall. I would spend an hour fighting the interface to fake something that would have been three lines of code.
The black box bothered me most. When an automation broke, and they do break, I was poking at someone else's system through a small window, guessing. I could see almost nothing inside it, testing was barely possible, and fixing the root cause was off the table entirely. Fiddle and hope was the whole toolkit.
The three fed each other in an ugly loop. Because I could see so little, I built clumsy workarounds. The workarounds ran more tasks, the extra tasks pushed the bill up, and the bigger bill made me resent a tool I could not even properly control. Once I noticed I was annoyed every single time I opened the thing, I knew it had stopped being the right fit for those jobs, even while it stayed perfect for the simple ones sitting right next to them.
A script as the spine
The replacement shape is simpler than it sounds. Each automation that mattered became one small script. The script is the spine. It does the plain mechanical steps in order: fetch this, check that, put the result over there. All the glue the visual tool was doing, the script does too, except now it is a page of code I can read top to bottom, test on my own machine, and repair at the root when it misbehaves.
It also lives in a file I own rather than a web app I rent. That alone removed a background layer of stress I had stopped noticing I carried.
A plain script has a hard limit, though. It can only do rigid, predictable steps, and most of my automations had one step in the middle that was never going to be predictable.
The judgment step
Almost every automation worth keeping had a fuzzy decision at its center. Is this email actually important. Which category does this message belong in. Is the tone of this note friendly or upset. Rigid scripts are terrible at those calls and language models are good at them, so the design splits the work. The script does the plumbing, and at the one point where judgment is needed it hands the question to a model and takes back a clean answer. Here is an email, does it need me today, yes or no. The script carries on with whatever came back.
The old visual tools could never do this part well. They give you rule boxes, subject contains this word, sender matches that address, and you end up stacking rigid little conditions in an attempt to imitate human judgment that never quite lands. With a model in the loop I stopped trying to spell out every case in advance. I describe what I am trying to decide, the model reads the actual thing, and each half of the split does the work the other half is bad at.
Why the model runs locally
The judgment step could call a cloud API, and for plenty of people that is the right choice. I run a smaller model on the same machine as the scripts, for three reasons.
Cost is the first. These automations run around the clock, and a model on hardware I already own adds nothing to the monthly bill, where per call pricing at that volume would quietly rebuild the exact bill I had just escaped.
Privacy is the second, and for mail it is the one I care about most. These scripts read my own correspondence and my own data, and I would rather none of it ever leave the house.
Control is the third. The local model does not change underneath me overnight, takes no outages on someone else's schedule, and keeps working when my internet connection does not.
The tradeoff is real. A model small enough for my machine is less sharp than the big hosted ones. For narrow calls like does this need me today, or which bucket does this go in, it is more than good enough, and the independence is worth the gap to me.
One migration, start to finish
The first automation I moved was inbox triage, the most annoying one I had. The old version was a tangle of rule boxes that I tweaked forever and that still misfiled things constantly, because rigid rules cannot judge importance. The new version is a short script that checks for new mail and asks the local model one question per message: given what this is about, does it need me today. The model reads the content and makes a sensible call. The script files everything accordingly.
Building and testing it took an afternoon. Running it adds nothing to my bills.
The part I did not expect to enjoy is how the tuning changed. When I want to adjust what counts as important, I edit one sentence in the prompt, the sentence describing what I care about right now, and the behavior shifts. The same adjustment in the old tool meant a dozen fiddly rule edits, half of them with side effects I would only notice a week later.
What got worse
The wins are the ones you would guess. The recurring bills for the migrated automations are gone, everything is visible and fixable now, and the judgment steps handle things no rule box ever managed.
The losses deserve equal space. This path needs some real coding, where the visual tool needed none, so it is genuinely not for everyone. I am also the support team now: when something breaks at an awkward hour there is no company to escalate to, just me and a file. And reliability became my job, because the hosted tool used to handle scheduling and retries, and now my own machine has to run these scripts on time without anyone watching.
I traded a monthly bill and a black box for control and responsibility. On the automations my work depends on, that trade was clearly worth it. For a lot of people it honestly would not be, and that is a sensible place to land.
Which automations to move
Most no code automations should stay exactly where they are. If one is simple, rarely breaks, and costs little, moving it is inventing work for yourself. The candidates are the few that have grown expensive, that keep hitting the ceiling of the visual editor, or that need a judgment call rigid rules cannot make. Those are the ones where a small script plus a local model genuinely shines.
There is no need to move everything at once either. I migrated the single most painful automation, ran it for a couple of weeks until I trusted it, and only then touched the next one. Start with your most annoying, most expensive flow, rebuild just that, and see how it feels before committing any further.
I write up each of these moves with the tradeoffs left in, and [there is more on xavierfok.com](/).
Get new guides and videos first — join the Telegram channel.