Your no-code automations are a liability nobody is talking about

A marketing agency reached out to me last week. Not because something was broken. Because of a quieter fear: nobody there fully knew what their own automations did anymore.

They'd been building for years. Smart people, solving real problems as they came up. A flow here to keep a dashboard alive, a flow there for a client process. Make scenarios stacked on Make scenarios. The kind of organic, useful mess that every growing operation produces.

Then someone said the thing out loud: “It mostly lives with one colleague now. What happens when he's sick? Or three weeks on holiday?”

That sentence is the whole problem. And almost nobody prioritises it until it's too late.

The thing nobody put a price on

Here's the trap with automation, and I say this as someone who builds it for a living: every automation you add is also a small debt. It does work for you, yes. But it also becomes something that has to be understood, maintained, and trusted by more than one person. Most teams only count the first half.

So you get the slow drift I saw at this agency. Multiple people touched the same systems over the years. Each “just quickly fixed” something a slightly different way. Nobody wrote down why. And the knowledge didn't disappear, it just concentrated. It pooled in the one person who happened to build the most.

That person is now a single point of failure for an operation that thinks it's automated. The automation didn't reduce the risk. It moved it, and hid it.

“We don't even know what's running”

The most honest line from that call wasn't about a bug. It was: we don't fully know what's running anymore.

Think about what that means. You can't assess a risk you can't see. You can't hand over a system you can't describe. You can't improve a flow you forgot exists. And you definitely can't tell a client their data is safe if you're not sure which scenario touches it.

This is the part teams underestimate: the danger isn't a broken automation. A broken one announces itself. The danger is a working automation that only one person understands. It runs perfectly, quietly, right up until that person is unreachable and something needs to change.

What I actually do about it (and it's boring on purpose)

When I get asked to fix this, people expect me to rebuild everything. I usually don't. The first job isn't building, it's seeing.

I get admin access to Make, and that's genuinely all I need, because from Make I can reach the systems underneath. Then I map the active automations only. Not the dead ones gathering dust, the ones actually running. For each I answer three plain questions: what does it do, in one human sentence? What does it touch, and what touches it? And how fragile is it, how hard would it be for someone else to keep it alive?

That's it. A one-time report, not a live dashboard, because the goal isn't to watch it forever. The goal is to turn “it's all in one person's head” into “it's written down, and anyone competent could pick it up.” And the same document that de-risks the operation usually exposes three or four automations you can merge, retire, or move somewhere cheaper. Visibility pays for itself.

The opinion, since you came for one

Automation without documentation isn't an asset. It's a liability wearing an asset's clothes.

If exactly one person at your company can explain how your automations work, you don't have automation. You have a dependency with a nice dashboard on top. The fix isn't more tools. It's making the work legible to more than one human.

So a small, blunt test. Pick your most important automated process and ask: if the person who built this vanished tomorrow, how long until we're in trouble? If the answer is “fast”, that's not an automation problem. That's a continuity problem, and it's worth solving before it solves itself.