Three ways to automate a business process, each with a genuine place. Choosing wrongly is not a disaster, but it does determine how much the automation costs to maintain for the next five years.
Low-code platforms
Visual tools where you assemble a flow from connectors and conditions. Power Automate, Zapier, Make and similar.
What you get: Hosting, scheduling, retries and error handling provided. Ready-made connectors to common systems. A visual representation that a non-developer can follow. Fast to build, and often no developer needed at all.
Where they stop being easy: Complexity. A flow with four steps is clearer than code. A flow with forty steps, nested conditions and loops is considerably harder to follow than the equivalent forty lines.
Other limits: Testing is awkward, so most changes are tested in production. Version control is limited, so "what changed and when" is hard to answer. Pricing is often per run, which is fine at hundreds of executions and expensive at hundreds of thousands. And you are limited to what the connectors expose.
Right when: the process connects common systems, the logic is moderate, business users should be able to see and adjust it, and volume is modest. That describes most small business automation — see comparing the platforms.
Scripting
Code written to do a specific job. PowerShell for Microsoft environments, Python for data work, shell scripts for system tasks.
What you get: Complete control. No per-run cost. Access to anything the system exposes rather than only what a connector supports. Handles complexity well, because complex logic is what code is for.
What you take on: Somewhere to run it. Scheduling. Error handling, which you must build rather than receive. Alerting. And a person who can read it — the point where scripts most often become liabilities, as covered in automation that survives its author.
Right when: the task is administrative rather than a business process, the logic is genuinely complicated, volume is high, or no connector exists for what you need. Administrative use is covered in PowerShell for business.
Custom code within an application
Automation built into a system your business runs, rather than sitting alongside it.
What you get: It is part of the process rather than attached to it. Proper testing. Proper version control. It benefits from the application's authentication, logging and error handling. It cannot drift out of step with the system it serves.
What it costs: Development time, and a release process for changes. Not appropriate for something you might want to adjust weekly.
Right when: the automation is central to how the business operates, when it must be reliable to a high standard, or when it needs to be part of an audit trail.
Reach for low-code by default, move to code when the flow becomes hard to read, and build it into the application when the process is genuinely core.
The questions that decide it
Who will maintain it in two years?
If the answer is a business user, low-code. If it is your IT provider, scripting is fine. If it is a development team, code inside the application is often best.
Be honest here rather than aspirational. "Anyone can maintain a visual flow" is true for simple flows and false for complicated ones.
How often will it run?
Per-run pricing is the most common reason businesses migrate off low-code platforms. Calculate the cost at your realistic volume in two years, not today's.
What happens if it fails at 2am?
If the answer is "somebody notices in the morning", any approach works. If the answer is "customers are affected", you need proper alerting and retry behaviour, which platforms give you and scripts require you to build.
How complicated is the logic?
The practical test: could you explain the flow to a colleague in two minutes? If yes, visual is fine. If it needs a diagram and caveats, code will be clearer.
Does it need to be auditable?
For anything with financial, regulatory or compliance significance, you need to know exactly what ran and what it did — see why audit logging matters. Platforms vary considerably in what they retain.
The hybrid, which is often right
Use the low-code platform for orchestration — triggers, connectors, notifications, retries — and call a small piece of custom code for the part that is genuinely complicated.
The pricing calculation, the data transformation, the decision with fifteen conditions. That lives in code, is properly tested, and is called as a single step from an otherwise simple flow.
You get a flow anybody can follow and logic that is maintainable, which is the best of both.
What not to do
Do not build a business-critical process as a flow nobody can read. If the visual builder has become unreadable, that is the signal to move that part into code.
Do not scatter automation across three platforms. Pick one, unless there is a clear reason.
Do not automate before agreeing the process. An automated bad process is a faster bad process — see where to start with automation.
Our automation team builds across all three approaches for UK businesses and will recommend the simplest one that will hold. Start a conversation.
