Workflow automation
Your automations are now a system nobody designed.
This page is not an argument against Zapier, Make or n8n. They are good tools and we use them. If you have four automations doing useful work, stop reading and go do something more valuable.
It is a page for whoever has forty. When the automations start depending on each other, when nobody can say what breaks if one is turned off, and when a failure is only noticed because a customer complains, the automation layer has quietly become the system of record.
The line
Automation connects systems. It should not be one.
A workflow tool is at its best moving information between systems that each hold their own truth. It is at its worst when it becomes the only place a business rule exists, because a rule living inside a chain of triggers is a rule nobody can read.
You have crossed the line when any of these are true. Nobody can list what would break if a scenario were disabled. A failure is discovered by a customer rather than by you. The same data is written by three different automations. Or the person who built them has left.
The costs nobody counts
Per-task pricing, and the failures you never see.
Automation platforms charge per task or per operation, so the cost grows with volume in exactly the way a busy month punishes you. That is the visible cost.
The invisible one is silent failure. A scenario that stops firing does not announce itself, and the gap it leaves is usually discovered weeks later in a reconciliation or a complaint. A system that owns the rule can tell you it failed. A chain of triggers mostly cannot.
The scope
What gets built, and what we leave alone.
What replacing the chain looks like
- The business rules written once, in one place, where they can be read
- The data with one owner, so three automations are not writing the same field
- Failures that are visible, retryable and logged rather than silent
- The genuinely good automations kept, pointed at the new system
- No per-task pricing, so a busy month costs nothing extra
- A record of what happened and why, which a trigger chain cannot give you
- Integrations to the systems that should keep their own truth: accounting, email, payments
What we will not do
- Replace automations that are working fine. Four good Zaps are four good Zaps
- Rebuild integrations that a platform already does well and cheaply
- Take on the project without mapping the existing scenarios first, because the undocumented ones are where the business rules are hiding
Most of these projects are hybrids. The rules and the data move into a real system, and the automation platform keeps doing what it is good at: talking to the long tail of other tools.
The sum
Platform fees, times sixty. Then add the failures.
Do it on your own number
Count the automation platform, the tier you were pushed onto by task volume, and the tools that exist only to hold data between steps.
Common questions
Answered plainly.
Should we replace Zapier or Make with custom software?
Only once the automations have become the system. If you have a handful doing useful work, keep them. The signal to act is when nobody can say what breaks if one is disabled, or when failures are discovered by customers.
We use n8n and self-host it. Does that change things?
It removes the per-task cost, which is a real advantage, and leaves the structural problem. Business rules spread across a chain of nodes are still rules nobody can read, and a workflow that silently stops is still a silent failure.
Can you keep some automations and replace others?
That is the usual outcome. The rules and the data move into a real system, and the platform keeps doing the integration work it is genuinely good at. Wholesale replacement is rarely the right call.
How do we know we have crossed the line?
Four tests. Nobody can list what breaks if a scenario is disabled. Failures are found by customers. The same field is written by more than one automation. The person who built them has left. Any two of those and it is worth a conversation.
What does it cost?
From $5,000, four to ten weeks, depending on how many scenarios exist and how much undocumented logic is inside them. Mapping what you already have is the first stage and it is where the real scope becomes clear.
Where to next
Bring the list of scenarios.
All forty, including the ones nobody remembers building. Twenty minutes going through them usually shows which are load-bearing, which are dead, and whether the rules should live somewhere a person can read them.