What We Build Automation With, and Why

The default stack

• Python for extraction, transformation and business logic — abundant skills, excellent libraries, easy to hand over
• PostgreSQL where we need our own store, which is less often than people assume
• Hosted queues and schedulers so failures retry rather than disappear
• Your existing systems as the source of truth wherever they can be
• Managed hosting, because a business without an infrastructure team should not be running servers

Why Python rather than something faster

For business automation, the constraint is almost never execution speed. It is how quickly the logic can be written, understood and changed by whoever comes next.

We optimise for the person who inherits this in two years. That rules out clever, and it rules out anything only one person on earth can maintain.

When we recommend no-code instead

Two systems, simple logic, modest volume, and someone non-technical who wants to own it. In that case a connector platform is faster to build, cheaper to start and genuinely better for you.

We say so and we do not bill for the build. The economics change once logic becomes conditional, volume rises, or a failure costs real money — that is when custom starts winning.

What we insist on regardless of stack

1. Idempotency — running the same input twice does not duplicate anything
2. Retry with backoff, because transient failures are most failures
3. A quarantine path so one bad record never stops the run
4. Alerting on absence, not just on errors — silence is the dangerous failure
5. An audit trail of what ran, on what, and what it produced

Where AI fits in the stack

Where the input is unstructured and a human could check the output in seconds: reading emails, extracting from documents, classifying enquiries. Everything else stays deterministic.

Matching, routing and posting decisions are rules, because you need to be able to read them, change them and explain them to an auditor.

Frequently asked questions