Watching an automation demo, the economics look absurd: an afternoon of clicking replaced a task someone did daily. The honest price sits elsewhere, because a demo automation and a load-bearing one are different products that happen to share a trigger. The demo handles the happy path. The load-bearing version handles the Tuesday when the payment API times out, the customer record is missing an email, and the same webhook fired twice, all before breakfast, all silently unless someone engineered the noise.
What a Real Automation Contains
- The trigger, with dedupe: real systems deliver events twice, and an automation that cannot tell sends the customer two invoices.
- The logic, with its edge cases enumerated: the rule everyone recites has exceptions everyone forgets until one executes.
- The actions, each able to fail independently, each needing an answer to what happens if the email bounces.:
- Retries and dead-letter handling: failures that queue for a human instead of vanishing.
- The log: when a customer says they never got it, somebody has to be able to know.
Each item is modest. Their product is the gap between the afternoon demo and the version a business stops checking up on, and that gap, not the visible logic, is what a quote is mostly pricing.
The Drivers, Ranked
Systems touched is the loudest driver: an automation inside one database is cheap, one spanning the CRM, the accounting package, and a messaging provider inherits three authentication schemes, three rate limits, and three vendors' outages. Decision complexity is next, priced by the number of paths that must each be correct. Then volume, which is pure arithmetic on per-task platforms and nearly free on owned infrastructure. And last, consequence: an automation that moves money or makes promises to customers carries a testing and audit burden a data-tidying script does not, and should.
Where the Per-Task Platforms Flip
Zapier-class platforms are the right first answer: no build cost, instant connectors, and at low volume the monthly bill is trivial. The flip has two blades. The visible one is metering, a per-task price that turns growth into a rising invoice, so the busier the business gets, the more its success costs. The quieter one is the architecture ceiling covered in the native-code analysis: logic scattered across dozens of individual zaps cannot be tested, versioned, or handed over, and error handling is whatever each zap remembered to include. The platforms are connectors that ended up holding business logic, and they hold it the way a junk drawer holds tools.
Buying Automation Sanely
- Prove the workflow on a per-task platform first: the cheapest possible test of whether the automation matters.
- Count the real monthly bill quarterly, platform fees plus the hours spent re-connecting broken zaps.:
- Move load-bearing workflows to owned code when the meter or the fragility says so, and leave the trivial ones where they are.:
- Insist on the log and the failure queue in anything custom-built: an automation without them is a demo being trusted with production.
The pattern matches the rest of the cost series: the price follows the number of situations handled correctly, and reliability is a situation count, not a feature. Paying for it once, on workflows that run thousands of times, is the arithmetic that makes custom automation the cheap option in the end.