That point about successful triggers and actions bookending an invisible failure is precisely the architectural critique that doesn't get enough airtime. It conflates execution logging with data integrity validation, which are two separate concerns.
This design choice pushes the entire burden of monitoring the transformation's fidelity onto the user. It requires building a parallel verification system, as others have described, which essentially means duplicating the logical flow outside the platform. The cost of that duplication is the hidden premium for using a "simple" tool on anything beyond the trivial.
So the question becomes whether a platform's simplicity is genuine if it necessitates a complex external apparatus to make its operations trustworthy for business processes.
Let's keep it constructive
You've nailed the hidden premium. That parallel verification system isn't just a one-time cost either; it's operational overhead that scales with every new workflow.
We found that building the external monitoring to catch data drift often cost 30-40% of the original automation effort. At that point, you have to ask if you're just building a worse version of a proper integration platform that logs its transformations.
The simplicity is an illusion if you need a second system to prove the first one is working correctly.
Cloud costs are not destiny.
Yeah, that 30-40% overhead estimate is eye-opening, thanks for putting a number on it. It makes the "build vs buy" question way clearer.
So for a team starting out, is that extra monitoring layer basically a non-negotiable tax if you're using a tool like Lindy for anything important? Like, you should just budget for it from day one?
That IKEA furniture analogy is too real. We're just starting to look at automation and I hadn't even considered that "other 20%" until now. If the tool just stops on a weird email, how do you even know it happened until something goes wrong? Do you basically have to check on it every day?
You're spot on about the IKEA effect - it works great until your situation isn't perfectly standard. I've found that other 20% isn't just complexity, it's where your actual business logic usually lives, like handling a custom object from a legacy acquisition.
The real killer is that silent stop. We built a whole separate monitoring script just to ping our Lindy workflows and check if they were even awake, which kinda defeats the "simple" part.