Automation Builds on n8n, Make and Zapier That Survive Failure

The platform question usually settles at volume. Under roughly 20,000 task runs a month, Zapier costs less than the time anyone spends maintaining a server, and we will tell you to stay there rather than sell you a migration. Above that, or the moment a workflow has to hold a file, reach an ERP over SFTP, or run inside your own network, self-hosted n8n on your infrastructure is the honest answer. Make sits between the two, and earns its place when logic branches heavily but the run count stays low. How these are built: Every workflow that writes to a CRM carries an idempotency key derived from the source record, so a webhook delivered twice does not create two deals. The second run finds the first and exits. Failures retry with backoff and then land in a dead-letter table in Postgres with the full payload, rather than in an alert email addressed to a shared inbox nobody reads. Each run carries a correlation ID that appears on the CRM record's timeline, so when someone asks in March why a lead was assigned the way it was in January, the answer takes two minutes instead of an afternoon. The integrations that are actually hard: Very little of this work is REST against a documented API. It is an ERP that drops fixed-width text or ISDOC invoice XML onto SFTP at 03:00, an ATS webhook that fires twice for one candidate and omits a field on the second delivery, a warehouse system whose only interface is a database view. We build against those with a staging step and validate on the way in. Malformed input stops and becomes visible; it does not get coerced into a half-populated contact that somebody discovers six months later. Czech and EU specifics are handled as standard: IČO validation and company lookup against ARES on inbound forms, VIES checks before a deal reaches invoicing, and VAT-relevant fields written where the accounting system expects them rather than where the CRM defaults put them. What you receive: The workflows themselves, on your account or your server, under your credentials. A runbook naming each workflow, what it does, what breaks it, and how to replay a failed run. Monitoring, meaning one view of failures across every workflow rather than per-platform notifications arriving in three places. And a written note of what we chose not to automate, with the reason. Not included: We do not take over an existing automation estate blind. If somebody else built it, that begins as an audit, priced separately, because inheriting undocumented workflows at a fixed price ends badly for both sides. We do not build outbound email sending at volume. We do not scrape sources whose terms forbid it. And we will not build a workflow whose only purpose is to copy a value into a field that should have lived on the object in the first place; that is a model problem and we will point at it rather than paper over it. Who this is not for: Teams who want a per-automation rate card. The cost here sits in deciding what should exist and in the failure paths, not in the node count, and pricing by workflow rewards building more of them. Also not for anyone who needs automations running before the lifecycle model is settled. We can build them in that order, and then charge again in six months to rebuild them, which we would rather say now than in the retrospective.