Automating without locking yourself in

Automation is sold on time saved. That’s true, and it’s measurable. What gets discussed less is what you accept in exchange.

Every automated workflow creates a dependency: on a vendor, on a pricing model, on a particular way of representing your data. That dependency causes no problem as long as everything holds. It becomes expensive the day something changes — and something always eventually changes.

The cost that doesn’t appear in the quote

A scenario I’ve seen several times. A small business gradually automates lead qualification, follow-ups, invoicing. Three years later, forty workflows run on a hosted platform. The vendor revises its pricing: annual cost triples.

The company has three options. Pay. Rebuild elsewhere, starting almost from scratch, because the workflows can’t be exported in any reusable form. Or go back to manual, which nobody knows how to do any more because the procedures vanished along with the people who followed them.

None of them is good. And the tipping point wasn’t the price revision: it was three years earlier, when nobody asked the reversibility question.

Three criteria that matter more than features

When I evaluate an automation platform with a client, I look at these three points first. Features come after — competitors always converge on them eventually.

Workflow legibility. Can your automations be exported in a format you can read, version and understand? A workflow stored only in the vendor’s interface doesn’t really exist for you. You can neither audit it nor rebuild it elsewhere.

Hosting control. Some platforms can be self-hosted, others can’t. This isn’t ideological: it’s about who decides on availability and price. A tool you host cannot be shut down by a commercial decision you didn’t make.

The pricing model. Billed per execution, per user, per connector? The first model punishes success: the better the automation works, the more it costs. Project your volume three years out, not your current volume.

What I apply in practice

I run my automations on an instance I host myself, on a machine dedicated to that — not on the server hosting client websites. Three reasons.

Failure isolation: an incident on a website must not stop the workflows processing incoming enquiries. Cost predictability: the price doesn’t move with execution count. Auditability: each workflow is a file — versioned, readable, rebuildable.

That choice has a cost — the machine needs administering. It’s justified above a certain workflow volume, and not before. For three simple automations, a hosted platform remains the right call: administration time would cost more than the subscription.

The real risk: knowledge evaporating

Technical lock-in can be worked around. Human lock-in, far less so.

When a process has been automated for two years, nobody on the team remembers how it worked before. The procedure isn’t written down anywhere. The edge cases, the exceptions, the implicit rules — all of that lived in the heads of the people who applied them. Automation made them unnecessary, then made them disappear.

The day the workflow breaks, nobody can take over manually. And nobody can rebuild it elsewhere, because nobody knows exactly what it did any more.

Hence a rule I apply systematically: document the process before automating it, not after. The document describes what the workflow does, in what order, with which rules and which exceptions. It lives alongside the workflow and is updated with it.

It’s the least spectacular deliverable of the engagement. It’s also the one with the most value three years later.

How to start properly

Begin with the most repetitive, best-understood process — not the most impressive one. Document it as it is actually performed today, irregularities included. Automate it. Measure the time genuinely saved over a month.

You’ll then know whether automation delivers on its promise in your context, before you’ve committed forty workflows and three years of dependency to it.