It worked for four months, then it didn't
You built it on a good Saturday. Deal closes, welcome email fires, task lands on someone's desk, row appears in a sheet. It was elegant. It ran for months and you forgot about it, which was the whole point. Then someone renamed a field. Or a stage got added to the pipeline because the sales process matured. Or an API version changed. And the Zap didn't stop — it kept running, on the wrong data, into the wrong place, until a client said something.
Now you have a folder of thirty-odd Zaps, several turned off because you're not sure what they do, a couple you're afraid to touch, and a general feeling that automation is more fragile than it was advertised to be. The instinct is to blame the platform. Hold that thought, because the platform is mostly innocent and the diagnosis matters.
A Zap encodes a step. It cannot encode an architecture.
Be fair to the tool: Zapier is excellent at what it is. It connects a trigger in one app to an action in another, reliably, without engineers. For that job it's one of the best pieces of software ever built, and we use it and Make in real client operations every week. The failure isn't in the execution. It's in what a Zap is structurally capable of holding.
A Zap holds one path. Inside it are assumptions: that the field is called Company Name, that Closed Won is the stage that means a deal is real, that this is the person who does the next thing. Those assumptions are load-bearing and they are undeclared — they exist nowhere but inside that individual Zap's configuration. There is no place in your business where it's written down that a won deal means these six things must happen. There are just six Zaps that each independently believe it.
So the failure mode is structural, not incidental. Change one thing in GoHighLevel and you've invalidated an unknown subset of thirty automations, with no index, no dependency graph, and no test. Nothing tells you which ones. Nothing tells the Zaps about each other. And most won't error — they'll happily execute against a field that's now empty, which is why the failure surfaces as a confused client rather than a red notification.
That's the whole sentence: Zapier isn't an operations strategy. It automates steps, and steps without an architecture underneath them are thirty private opinions about how your business works, drifting out of sync with the business and with each other.
What the drift costs
The first cost is trust, and it's the expensive one. After the second silent failure you start checking. You verify the welcome email actually went. You spot-check the sheet. Congratulations: the automation now costs you attention instead of saving it, which is the precise opposite of the thing you built it for. A system you don't trust is worse than no system, because you're paying for it and doing the work anyway.
The second cost is calcification. Once a founder has been burned twice, the pipeline stops changing — not because the process is right, but because changing it means breaking things you can't inventory. Your operation gets frozen by its own automation. That's a genuinely awful place to be, and it's common enough that we look for it specifically.
The third is the conclusion you draw. Most founders don't conclude "I built steps without an architecture." They conclude automation is overhyped and go back to doing it by hand — which is the most expensive possible response to a correct observation about the wrong cause.
What has to exist underneath
Four things, and none of them are a platform migration. First, one written definition of your operating events — what a won deal means, what a new client means, what happens on each, in one document a human can read. That document is the architecture. The Zaps become implementations of it rather than the only copy of it.
Second, one system of record per entity, so no automation has to guess where truth lives. Third, error handling that's actually pointed at a human: a failure lands in Slack, with the record attached, addressed to a named owner — not a digest email to an address nobody reads. Fourth, an owner and a review cadence. Automations are part of the operation, which means somebody's job includes them, which means when the pipeline changes, the change list exists.
Then the tool choice becomes easy and unemotional. Simple, stable, low-branch paths: Zapier or Make, genuinely, keep them. Real branching, real state, anything where a wrong result is expensive or the logic has opinions: n8n, Retool, or a small piece of custom code that can be versioned, tested, and reviewed like the piece of infrastructure it actually is. Most operations we build are a mix, and the mix is the point.
This is the Automation pillar
OPERATE puts this in Automation, and there's a line in the pillar that's precisely the correction here: automation shouldn't be a tool — it should become a teammate. A tool is something you pick up, which means it still depends on your attention. A teammate knows the job. A folder of thirty Zaps is thirty tools. It has never been a teammate, because no part of it knows what your business is trying to do.
The other line that applies: if you approach automation with the same mindset you'd use to coach a team member — test, refine, improve — then every failure becomes a step towards mastery. Your Zaps breaking isn't evidence that this doesn't work. It's evidence that you built the execution before the design, which is what every founder does, including us, the first time.
If you have a folder of automations you can't inventory and are afraid to touch, that's what the OPERATE Report untangles — what you have, what depends on what, what should be rebuilt with an architecture underneath, and honestly, what should just stay in Zapier because it's fine.
Zapier isn't an operations strategy. Your Zaps break because each one privately believes something about your business that nothing wrote down — and the day the business changes, thirty automations become wrong at once and none of them say so.