Why we ship automation as licensed software, not scripts

A script that works on your machine on a Tuesday is a demo. Everything that happens after that is the actual product.

What breaks a script

Automation lives against systems you do not control. Interfaces move, endpoints change, a dependency ships a breaking release. A script has no answer to any of that — someone has to notice it broke, find it, and fix it by hand. Usually after it has been quietly failing for a week.

What we ship instead

Every platform we deliver carries the same four things:

A real installer. Per-user install, isolated data directory, no admin rights required, and an uninstall that actually removes things. Operators should never touch a Python path.

Licensing. Hardware-bound activation with a background heartbeat, so a build cannot be copied around and so we can see which version each seat is running.

Silent self-updates. When we fix a broken flow, every seat has the fix the next time it starts. This is the single largest difference between a script and a product — the fix reaches the user without anyone asking.

Diagnostics. A health check the operator can run before calling us, and structured logs we can read after. Most support tickets end at the health check.

The economics

Clients sometimes ask why they cannot just get the script. They can — and it costs less on day one and more every month after. The delivery layer is where the maintenance cost goes to die: no remote-desktop sessions to patch a machine, no version drift across seats, no silent failures found three weeks late.

The line we draw

If something is genuinely one-off — a migration, a scrape that runs once — we write the script and hand it over. That is the right tool.

But anything that runs weekly, against a system somebody else controls, is a product. Building it as anything less just moves the cost somewhere you cannot see it.