im·a·cto

$ cat writing/no-code-is-a-loan.md

← the_log

No-Code Is a Loan

No-code glue is real speed at the edge and a hidden mortgage in the core. A note on where the drag-and-drop tools belong, and where they quietly become the wall.

The flow worked the first time. That was the problem.

It’s a Friday. A customer needs a welcome email when they onboard, plus a Slack ping to their success rep. You open the automation builder, drag four nodes onto the canvas, wire them together, hit save. Ten minutes, no deploy, no pull request. It fires. You move on. That felt like the whole promise of the tools, delivered.

Eight months later a support ticket lands: new customers aren’t getting the email. You open the canvas. Nobody remembers building half of it. Maybe a node’s default shifted under you in a platform update. Maybe someone tweaked a filter back in March. There’s no way to know which, because a visual flow has no diff and no history you can read. No test failed, because there was never a test. You found out from a customer.

That gap, between “it fired on Friday” and “I heard about it from a customer,” is the whole essay.

the speed is real

This is everywhere right now. Every team is gluing AI calls, webhooks, and a stack of SaaS together in n8n, Zapier, Make, some builder with a canvas. And it’s genuinely fast. I won’t pretend the speed is fake. At the edge it’s a gift: an internal notification, a nightly sync, a scrappy integration nobody’s payroll depends on. Reach for it there and I’ll cheer you on.

The trouble starts later, and quietly. Nobody sits down and decides to run the business on a drag-and-drop canvas. It happens one node at a time. The onboarding flow that was a convenience becomes the onboarding flow, singular, the only one. The glue becomes the wall, and you don’t notice the day it crosses over.

the balloon payment

Here’s the reframe I keep coming back to. No-code is a loan. You borrow speed today against a payment later, and the payment comes due the exact day the glue turns load-bearing and something breaks under it. The train only moves as fast as the tracks it runs on, and a visual builder lets you skip laying track and just run the train across the dirt. That’s fine at low speed on a short haul. Put real weight on it, run it every day, and you find out why track exists.

This isn’t taste. The DORA research behind the Accelerate book is blunt about what separates teams that ship fast and safely from teams that just ship: they keep everything that defines production under version control, and they test it automatically. A canvas fails both by construction. It doesn’t live in git, so there’s no review, no revert, no record of who changed what. And you can’t write an honest test against a flow you assemble by dragging boxes, so every change is a deploy straight to prod with your fingers crossed.

the fix is moving the logic, not the tool

I’m cleaning up exactly this right now. At Phoneware, a UCaaS platform, the customizations had grown into two piles: portal features living in per-customer JavaScript bundles, and app backends stranded in n8n flows. Every customer a little different, and every difference a place a change could silently break. The fix wasn’t more flows or more bundles. It was pulling customization out of code and glue and into data: a manifest API that cascades reseller to domain to role, all in one TypeScript monorepo. A customer’s configuration is a value now, not a fork. Changing it is a pull request a compiler and a test suite get to see before any customer does.

Notice what moved. The tool didn’t matter as much as the shape. The logic stopped being trapped in a canvas and became something you can diff, review, revert, and reason over.

the second bill

There’s a newer bill on that loan, and it’s the one most people miss. A fleet of agents can reason over a typed monorepo. It can read the manifest, follow the cascade, change a value, and let CI tell it the blast radius before anything ships. It cannot reason over a canvas. The logic trapped in a visual flow is invisible to the tools that are supposed to be multiplying you. When generation is free, your leverage lives in the parts of the system an agent can actually read. Wire your core into a drag-and-drop builder and you’ve hidden it from the one thing that was going to make you faster.

You bought speed on Friday and mortgaged your leverage by Monday.

where it belongs

So I’m not here to trash no-code. Every tool is a call about where it fits, and this one fits the edge: the throwaway, the internal, the thing that can fail at 3am and nobody feels it. Drag the nodes and ship. The moment a customer can feel it, or the moment your business would stop if it stopped, it’s stopped being glue. It’s infrastructure, and infrastructure earns a repo, a test, and a diff.

The honest question was never “can I build this without code?” You almost always can. The question is “when this breaks in eight months, how do I find out before my customer does?” If the tool can’t answer that, you didn’t save the time. You borrowed it.

Written with Claude, and I’ll say so plainly. The frame, the Phoneware call, and the opinions are mine. The model did a lot of the drafting. Same as the rest of this site, and same as the argument it’s making.

© 2026 — written by a human, with help, and said so canonical jasonwaldrip.com · delivered through The Bushido Collective