Every developer's first reaction to "we need to sync X to Y and post to Z" is the same: I'll write a script. A cron entry, a few API clients, maybe a queue if it gets serious. It's a fifteen-minute job and you own every line.
That instinct is correct often enough to be dangerous. Because the cost of an internal automation almost never lives in the part you were picturing — the business logic — and almost always lives in the part you weren't: the glue. This is a build-vs-buy essay, but not the enterprise-procurement kind. It's the one engineers actually face, quietly, a dozen times a year, and usually answer by reflex.
What the script actually turns into
The fifteen-minute script is real. Here is what it becomes six months later, when it's load-bearing:
- The third-party token expires, so now there's a refresh flow.
- One endpoint paginates, so there's a cursor loop.
- The API rate-limits under load, so there's backoff and retry.
- A webhook has to be received, which means a public endpoint, signature verification, and something listening 24/7.
- A run fails at 3 a.m. and nobody notices for two days, so there's alerting, and then a dead-letter path, and then a way to replay.
- Someone asks "did it run yesterday?" and you realize there are no logs anyone but you can read.
- You go on holiday and discover the automation has a bus factor of exactly one: you.
None of that is the feature. All of it is table stakes for the feature not to embarrass you. And you will re-solve every item on that list for the next automation, and the one after that, because a bespoke script shares nothing with its neighbours.
A workflow platform is, stripped of marketing, a runtime that has already solved that list once so you don't solve it per-integration. Retries, scheduling, webhook receivers, credential storage, run history, a UI someone else on the team can read — those come with the box. You're not buying "no-code." You're buying the glue, amortized.
The decision line
So the honest question isn't "am I too good for a no-code tool" (a framing that flatters the ego and costs you weekends). It's three narrower questions:
1. Is the value in the logic, or in the plumbing? If the hard part is a genuine algorithm — a matching engine, a pricing model, anything where the reasoning is the product — hand-code it. If the hard part is "call five APIs in the right order and don't drop anything," that's plumbing, and plumbing is exactly what a platform commoditizes.
2. Who needs to read and change it? A script is legible to whoever wrote it. If the workflow has to be observable — edited by a teammate, audited after an incident, understood by someone six months from now — a visual graph with per-node run history beats a clever script that only lives in one head.
3. How often does the surface change? APIs you glue together change. A platform absorbs a lot of that churn (connector maintained upstream, auth handled centrally) so you're not shipping a patch every time a vendor rotates an endpoint.
If two of those three point the same way, the reflex answer is usually the wrong one.
"Buy" does not mean "give up code"
The reason a lot of engineers refuse this trade is a bad assumption: that adopting a platform means surrendering to a drag-and-drop sandbox where the one thing you actually need is impossible. That's true of some tools. It is not a law.
We run our entire content pipeline this way — around ten workflows, roughly two hundred nodes, self-hosted on a single box — and it stayed tolerable to an engineer for one reason: the platform we chose treats code as a first-class citizen. When the visual abstraction is enough, we use it. When it leaks, we drop into a Code node and write plain JavaScript or Python, or fire an HTTP request at whatever API has no pre-built connector. For the part that matters most — the model calls on our critical path — we skip the platform's prebuilt "agent" abstraction entirely and call the API over HTTP ourselves, because we want to own the prompt, not hand it to a black box.
Two properties made it a real engineering tool rather than a toy:
- Workflows are just JSON. Every workflow exports to a file, so our automations live in Git next to the rest of the codebase. Changes go through a pull request; deploys run from a script; a bad change is one
revert away. That single property is what moved it from "a dashboard I click around in" to "infrastructure I can reason about."
- It fails loudly. We have a hard rule against silent fallbacks: a failing step throws and surfaces to our team chat, it does not quietly return a cheaper result and let a broken run look green. Whatever you adopt, check that you can make it fail like this — a platform that swallows errors to look friendly is worse than the 3 a.m. script.
Here's the shape of the thing you're not rewriting per-integration once the runtime owns it — the idempotency guard that keeps a retry from double-posting, expressed as the platform primitive it becomes rather than fifty lines of bespoke plumbing:
// A non-idempotent step (post to a scheduler, write a row) guarded by a status flag,
// so a retry or a manual re-run can't fire it twice. In a hand-rolled script this is
// yours to build, test, and remember. On a workflow runtime it's a node + a column.
const already = await db.oneOrNone(
`select 1 from outbox where job_id = $1 and status = 'sent'`,
[item.job_id]
);
if (already) return { skipped: true }; // safe to replay
await publish(item); // the only non-idempotent line
await db.none(
`update outbox set status = 'sent', sent_at = now() where job_id = $1`,
[item.job_id]
);
The point isn't the ten lines. It's that on a bespoke script you write, test, and maintain this — and the retry logic, and the alerting, and the replay path — for every automation you own. On a runtime you write it once as a pattern and the rest of the list comes free. Across months of unattended runs, that's the difference between a stack you trust and one you babysit.
Where I still build
This cuts both ways, or it's just advocacy. I still hand-code when:
- The logic is the product. If the workflow is a thin wrapper around one genuinely hard function, the platform is overhead around the only interesting part.
- I need a guarantee the platform won't give me. Exactly-once across a boundary it doesn't control, a custom concurrency scheme, sub-second latency budgets — if you need it and can't express it, don't fake it inside a tool that can't promise it.
- It's genuinely throwaway. A one-off backfill doesn't need a runtime. Write the script, run it, delete it.
And the trade has a real bill, which you should price in with open eyes: a workflow platform still expects comfort with APIs and JSON to do anything ambitious, and if you self-host you own the upgrades and the backups like any other service. There's also a licensing subtlety worth reading before you commit — the tool we use is source-available under a fair-code license, not OSI open source: self-host and automate your whole company for free, but you can't turn around and resell it as your own hosted product. For internal use that line never bites. If you're building a product on top of it, read it first.
The actual takeaway
Build-vs-buy for internal automation isn't a values question about whether real engineers use no-code. It's a leverage question. Your time is worth the most where the reasoning is hard and worth the least re-implementing token refresh for the fourth time. Adopt a runtime for the plumbing; keep your hands on the logic; and pick a tool that lets you drop to code so "buy" never means "stuck."
If you're at the point of actually choosing one, the platforms differ more in how they bill and how far you can drop to code than in what they can do — we wrote up a neutral roundup of the main automation platforms that sorts them by exactly that, since the per-execution-vs-per-task billing model tends to decide the question more than any feature checkbox does.
The reflex to write the integration yourself is a good instinct pointed at the wrong problem about half the time. Learn to tell which half.
