How we actually pick automation tools

Every few weeks a new "AI automation platform" launches with a demo video that makes it look like it replaces everything you already run. Almost none of them do. The honest version of picking tools is duller than that, and it's the version that actually holds up six months later.

Does it live inside the client's accounts?

The first filter isn't features — it's ownership. We build inside the tools a business already has (their Google Workspace, their CRM, their n8n or Make instance) wherever that's possible, rather than introducing a new platform they now have to pay for and maintain forever. A tool that requires us to become the permanent operator is a tool we're wary of.

Can it fail loudly?

Automations that fail silently are worse than not having them. Before anything ships, we want to know: what does a failure actually look like, and does someone get told about it within minutes, not days. If a platform makes that hard to wire up, that's a real cost, not a minor inconvenience.

Is the pricing model going to survive scale?

Per-task or per-execution pricing looks cheap in a demo and gets expensive fast once a workflow runs thousands of times a month. We model rough monthly volume before committing a client to a platform, not after the first invoice surprises them.

Does it have an exit?

If a platform disappeared tomorrow, how much of the logic could be rebuilt elsewhere in a week? Vendor lock-in isn't automatically disqualifying, but we want it to be a conscious trade-off, not something a client discovers by accident two years in.

None of this is exotic. It's the same discipline good engineering has always required — it just gets skipped more easily when a demo is impressive enough to short-circuit the questions.