# When to move an automation off no-code

> No-code is the right way to find out whether a workflow is worth having. These are the signs it has outgrown the tool, and how to move it without a big rewrite.

Source: https://simasrazinskas.com/blog/ai-automation-vs-no-code  
Published: 2026-06-30  
Updated: 2026-10-07  
Tags: Automation, No-code, Production

No-code tools are the right way to find out whether a workflow deserves to exist.
They are a poor place to keep one that the business depends on.
The skill is noticing when the second situation has quietly replaced the first.

## Start in the no-code tool while mistakes are cheap

If a workflow is reversible, low in volume and mostly moves data between tools, build it in n8n, Make or Zapier.
The only question that matters early is whether anyone needs the result.
A visual flow answers that in an afternoon, and nobody has to maintain a service for an idea that may not survive the month.

## The signs it has outgrown the tool

The trouble starts with properties these tools keep out of sight:

- **Retries and duplicates.** The source sends the same event twice, or a step times out after it already did its work, and the run repeats a side effect.
- **State across runs.** The flow needs to know what happened last time, so it grows a spreadsheet or a lookup table on the side.
- **Partial failure.** A run dies halfway through and there is no record of which half happened.
- **Permissions and audit.** Someone asks who changed a refund, and the answer is a shared account.

Once a stuck run means a lost order, a wrong refund or a customer who never gets a reply, the workflow has become production software, whatever tool it lives in.

## What the replacement looks like

At a consumer subscription business I moved help-desk ticket ingestion out of n8n into a Go service, and built a second service to take over enriching tickets with purchase data from the warehouse.
Both are small services built around a Postgres table that holds the work.
A worker claims a row, does the job and records the outcome; a failure stays as a row with its error and its next retry time.
That one change is most of the value, because "did it run?" becomes a query instead of an investigation.

The [ingestion case study](https://simasrazinskas.com/work/idempotent-webhook-ingestion) and the [job queue case study](https://simasrazinskas.com/work/durable-job-queue) show the details.

## Move one flow at a time, and run both

Keep the working no-code flow as the specification of what the business needs.
Rebuild the risky part first, run the new version next to the old one, and compare their output on real traffic before switching.
The enrichment service ran in shadow mode, with parity checks against the legacy flow, before it became the live worker.

Not every migration should finish.
I also rebuilt another family of no-code flows and ran it in dry-run next to the originals; it never cut over, and I removed it.
A side-by-side run makes that call cheap, because the old flows keep working while you decide.

## A rule of thumb

Leave a workflow in the no-code tool while its failures are cheap and visible.
Move it into code when a failure costs money or trust, or when nobody can say whether last night's runs all happened.

## Start with one process

A one-hour call costs €80. Afterwards you get a written plan, whether or not we work together.

[Book a call](https://simasrazinskas.com/book-me) · [simas@simasrazinskas.com](mailto:simas@simasrazinskas.com)