The one idea
There are four categories of automation tool, and choosing between them is a trade of convenience against control.
More convenience means faster to build, easier to hand over, and less control over cost, data and behaviour. Less convenience means more setup and more maintenance, and nobody can change the terms on you.
Neither end is correct. Knowing which end you are at is.
Some tools do the work for you on their computers. Some run on yours. The first is quicker to start; the second is yours to keep.
Match the tool to volume, sensitivity and lifespan. Low volume and non-sensitive: hosted. High volume or regulated data: self-hosted or scripts.
Trade operational burden against per-execution cost and data residency. Hosted connectors externalise ops and integration maintenance; self-hosted internalises both in exchange for control and predictable cost.
The four categories
| Category | Runs on | Strong at | Costs you |
|---|---|---|---|
| Hosted connectors | Their servers | Speed to build, hundreds of ready integrations | Usually priced per task or per run; your data passes through them |
| Self-hosted workflow tools | Your server | Control, data stays yours, predictable cost | You run the server, patch it, back it up, fix it at 11pm |
| Spreadsheet scripting | Inside the spreadsheet platform | Automating work that already lives in a sheet | Tied to that platform; awkward beyond a certain size |
| Scheduled scripts | A runner you configure | Full power, versioned, testable | You write and maintain actual code |
Named examples, so the categories are concrete: Zapier and similar services are hosted connectors. n8n can be used hosted or run on your own infrastructure, which is why it appears in conversations about both. Google Apps Script is spreadsheet scripting attached to Google Workspace. GitHub Actions can run a script on a schedule as well as on code changes.
Fact Hosted connector services generally charge based on how much work they do for
you — per task, per run, or per execution — so cost scales with volume rather
than being flat.
Recommendation Check current pricing, limits and data-handling terms on the provider's own
page before committing. These change, and a summary written at any point in time
will be wrong eventually — including this one.
Choosing
Four questions, in this order
1 of 4How sensitive is the data?
If it is customer personal data, health information, financial records, or anything under a contract that restricts where data may go — a hosted service means that data traverses a third party. That may be perfectly acceptable with the right agreement in place, but it is a decision requiring someone's approval, not a default.
If the data is sensitive and you cannot get that approval, this question alone decides the category: self-hosted or scripts.
A five-person team wants new form submissions in a shared sheet with a channel notification. Low volume, no sensitive data, needs to be maintainable by whoever is around.
Hosted connector. Built in twenty minutes, readable by anyone, and the cost at that volume is negligible. Writing a script here would be worse — not because scripts are bad, but because nobody else on that team can maintain one.
A company syncs 40,000 customer records nightly between two internal systems. High volume, personal data, runs indefinitely.
Wrong choice: a hosted connector, where volume drives cost and personal data leaves the organisation for no functional reason. Right choice: a scheduled script or a self-hosted workflow inside their own network. It takes longer to build and the cost stops being a function of how successful the company gets.
Try this
Match each to a category, and say what you are giving up.
- A one-off: move 200 rows from an old system to a new one.
- Post a daily summary of yesterday's sales to a team channel.
- Nightly reconciliation of two databases containing customer payment details.
- When a form is submitted, add a row and email the submitter.
Your challenge
Level 3 · IndependentTake an automation you want and write a one-page comparison: how you would build it in a hosted connector, and how you would build it as a scheduled script.
For each, state: build time, ongoing cost shape (not a number — whether it scales with volume or is fixed), where the data goes, what breaks it, and who can maintain it after you.
You have succeeded when you can defend your choice to someone who prefers the other one. If you cannot argue the opposite case, you have not understood the trade-off yet.
What people usually get wrong
- Choosing by popularity. The tool your favourite creator uses was chosen for their constraints, not yours.
- Ignoring where the data goes. Routing personal data through a third party is a decision that needs approval, not a default of the tool you picked.
- Not checking how cost scales. Hosted pricing is usually per unit of work. Fine at low volume; check what it looks like at ten times your current volume.
- Self-hosting without accepting the ops. Your own server needs updates, backups and monitoring. "It's free" ignores the hours.
- Building in a tool nobody else can open. When you leave, it becomes an untouchable box that everyone is afraid to turn off.
- Not versioning visual workflows. A script lives in Git. A drag-and-drop workflow often has no history — someone changes a step and there is no way back and no record of what it used to do. Export it periodically.
How someone experienced does it
Experienced people build the first version in whatever is fastest, on purpose, and treat it as a prototype. It proves the process is right and reveals the exceptions. Only when it survives a month do they consider rebuilding it properly.
They also separate the logic from the plumbing. If the actual work lives in a small script, the connector merely triggers it — and moving between platforms later means rewiring the trigger rather than rebuilding the logic. This one habit turns migration from a rewrite into an afternoon.
And they check on their automations deliberately. A monthly fifteen minutes: which ran, which failed, which is still needed. Most organisations have automations that stopped working months ago and automations doing work nobody needs, and both are found by looking rather than by waiting.
When not to use this
No-code is the wrong choice when:
- The logic is genuinely complex. Twenty branching conditions in a visual editor is harder to read than thirty lines of code, not easier.
- You need real testing. Scripts can be tested automatically before they run against real data. Most visual tools cannot.
- The data cannot leave your control. No amount of convenience overrides a contractual or legal restriction on where data may go.
- It needs to be fast. Hosted platforms add latency and queueing. If the answer must come back in under a second, this is not the layer for it.
Prove it
Build one automation, then write its handover note: what it does, what triggers it, what breaks it, how to turn it off, and who to contact.
Five lines. Give it to a colleague and ask if they could take it over. If they say no, you have built something that will become a problem, and you have found out cheaply.
Keep learning this
Paste this into any AI assistant. It turns the assistant into a tutor that tests you instead of just answering you.
Act as an experienced practitioner who is good at teaching. I have just learned choosing between no-code, low-code and scripted automation. Assume I am intelligent but relatively new to this — treat me as intermediate level. Work through this in order, and wait for my reply at each step: 1. Ask me 5 questions that test whether I actually understood choosing between no-code, low-code and scripted automation. Do not reveal the answers yet. 2. After I answer, tell me which parts I got right, which I got wrong, and which I only half-understand. Explain only what I misunderstood — do not re-teach what I already know. 3. Give me one practical challenge based on something I could genuinely encounter at work or in daily life. Do not solve it for me. 4. Evaluate my solution the way an experienced person would judge it, including what a professional would have done differently. 5. Tell me what to learn next, and why that comes next. 6. Give me trustworthy sources for deeper study — prefer official documentation, primary research or standards bodies over blogs and videos. Rules for you: no buzzwords. No motivational filler. Say "I'm not certain" when you are not certain, and tell me which parts of your answer I should verify myself. Clearly separate facts from your recommendations and your opinions.
Become independent at this
Use this when you want a path from where you are to actually good, with checkpoints you can test yourself against.
I want to become independently capable at automating work without writing much code — not permanently dependent on AI, tutorials or step-by-step guides. Design a progression for me with five stages: Beginner, Guided practice, Independent practice, Real-world application, Professional level. For each stage tell me: - what I must know - what I must be able to do without help - the mistakes people make at this stage - one practical challenge - one real project that would prove I reached this stage - one way I can test myself honestly Then tell me the signals that I am ready to move to the next stage, and the signals that I have skipped ahead too early. Keep the theory to the minimum I actually need. Focus on ability I can transfer to situations you and I have not discussed.