Somewhere in your business there is a person who exports a report every Monday, pastes it into a spreadsheet, renames three columns, and emails it to four people. It takes forty minutes. It has taken forty minutes a week for three years.
That is roughly 100 hours. Automating it is a couple of hours of work in any modern low-code tool, and the argument for doing so is unanswerable.
So this note is not an argument against low-code automation. It is an argument for being deliberate about it, because the same properties that make these tools fast to build in make them very easy to accumulate badly — and the failure mode arrives eighteen months later, quietly, when nobody can explain why the invoices stopped syncing.
What these tools are actually good at
The sweet spot is narrow and genuinely valuable: moving structured data between systems that don’t talk to each other, on a trigger, with light transformation.
Concretely, the automations that consistently earn their keep:
- Form submission → CRM → notification. A lead fills in a form, a record is created, the right person is told. No human retypes anything.
- Scheduled reports. The Monday export above. Pull, reshape, deliver, on a timer.
- Approval chains. A request goes to a manager, the answer is recorded, the requester is told. The value is the audit trail as much as the routing.
- Document generation. Data in, PDF out, filed and emailed. Quotes, certificates, onboarding packs.
- Cross-system sync. Your accounting package and your inventory system both need to know a sale happened, and neither integrates with the other natively.
- Alerting on business conditions. Stock below a threshold, a payment overdue by fifteen days, a customer inactive for ninety.
What all of these have in common: the logic is simple, the volume is modest, and a human notices reasonably quickly if it stops.
Where it turns into a liability
The trouble starts when low-code automation drifts out of that zone. Four warning signs, in rough order of how often we see them:
1. It became the system of record. An automation that copies data between two systems is fine. An automation where the only place a piece of business data exists is inside a workflow tool’s run history is not. If someone asks “when did we approve that?” and the answer lives in a Zap that retains 30 days of logs, you have a records problem wearing an automation costume.
2. The logic outgrew the canvas. Fifteen steps with six branches is where visual builders stop being clearer than code and start being considerably worse. You cannot diff it, you cannot review it, you cannot search it, and you certainly cannot test it. When the flowchart no longer fits on a screen, that is the tool telling you something.
3. Nobody knows it exists. This is the big one. Low-code tools are usually bought on a personal card by whoever needed them, and the automations they hold become invisible infrastructure. We have walked into businesses where a critical daily process ran from a personal account belonging to someone who left the company in March. It worked, right up until the credit card expired.
4. Failure is silent. Most of these tools do notify on error — to the email address of whoever built the flow, which is often nobody’s shared inbox. An automation that has been failing for six weeks is worse than no automation, because everyone downstream has stopped checking manually.
The question that decides it
Before building anything, ask: what happens if this runs wrong for a month and nobody notices?
If the answer is “we send a slightly stale report” — build it in the low-code tool, today, and don’t overthink it.
If the answer touches money, compliance, customer commitments or anything you would have to explain to an auditor, then the automation needs the things that real systems have: someone who owns it, monitoring that reaches a human, a record of what it did, and a documented way to run the process manually while it is broken.
That is not an argument for writing it in code instead. It is an argument for treating it as production, whatever it is built in.
Choosing a tool, briefly
| Tool | Best when | Watch out for |
|---|---|---|
| Zapier | Simple A→B, huge app catalogue, non-technical builder | Cost climbs steeply with task volume |
| Make | Branching logic, visual clarity at moderate complexity | Gets tangled past ~20 modules |
| n8n | You want self-hosting, no per-task pricing, real code escape hatches | You now run a service — it needs updates and backups |
| Power Automate | You are already deep in Microsoft 365 | Licensing is genuinely confusing; premium connectors surprise people |
| Google Apps Script | Small jobs inside Workspace | It is code, so it needs a home and a reviewer |
Honest advice: the tool matters far less than whether anyone owns the result. We have seen excellent outcomes on all of these and disasters on all of them.
The one structural consideration worth weighting: self-hosted (n8n) versus hosted (everything else). Self-hosting removes per-task pricing and keeps your data on your infrastructure, which matters if the automations touch customer records. It also means you are running another service that needs patching, monitoring and backup. Neither answer is wrong; pretending the trade-off doesn’t exist is.
Knowing when to graduate
Low-code is a starting point, not a destination, and there is a specific moment to move a process into a real application:
- It runs often enough that per-task pricing has become a real line item
- The logic has branches that need testing rather than hoping
- Two or more people need to change it, so you need review and history
- It handles data you would be embarrassed to see in a third-party run log
- You have hit the tool’s ceiling and are building workarounds around workarounds
None of that means throwing away what you built. The low-code version did its most valuable job already: it proved the process, in production, with real data, cheaply. That is a far better specification than anything you would have written up front — and rewriting from a working automation is one of the easiest kinds of software project there is, because the requirements are no longer guesses.
What good looks like
If you take one thing from this, take the checklist. An automation is production-ready when:
- It has an owner — a named person, not “the ops team”
- It lives in a company account, not someone’s personal login
- It fails loudly — errors reach a shared inbox or chat channel that someone reads
- It is documented — one paragraph: what it does, what triggers it, what breaks it
- It can be done by hand — a written fallback for the day it is down
- It is reviewed — someone looks at the list of active automations twice a year and deletes the dead ones
Six things. None of them takes longer than the automation itself, and together they are the difference between a tool that compounds and a pile of invisible dependencies.
We do automation design and review remotely — mapping a process, building it, or untangling a set of workflows that grew organically and now nobody quite understands. If that sounds like your Monday morning, get in touch.