Your automation "expert" built you a time bomb, and they'll ghost the second it goes off.

Can I vent for a sec. ​ Every couple weeks I get the same call. Some business owner who paid an "automation expert" good money, and now they've got a workflow that works... sometimes. On a good day. If the wind's blowing the right way. And they want me to figure out why their "fully automated" system needs a human babysitting it around the clock. ​ So let me tell you what I keep finding, because it's almost always the exact same stuff. ​ The guy they hired jumped straight in and built a thing that does X. Cool. Except he never once asked what the business actually does, or what this workflow touches, or what happens three steps downstream when it fires. He was so locked in on how to build it that he never stopped to ask why any of it should work the way it does. And that's where the whole thing starts going sideways before he's even finished. ​ Error handling? There isn't any. The happy path works great, looks like absolute magic in the demo. Then one day a field comes through empty, or some API decides to rate-limit them, and the entire thing faceplants on the spot. Now the client's sitting there with a dead workflow and no clue how to fix it, because nobody ever taught them, so they paste the thing into Claude and pray. And when the miracle doesn't show up, surprise, the builder's already gone. Ghosted. So now this poor owner thinks automation itself is a scam, when really they just hired someone who builds for the demo and dips the second it gets hard. ​ Then you've got the logic that works by pure accident. I've opened up filters that spat out the right answer for completely the wrong reason, purely because the test data happened to be squeaky clean that day. Production data is never clean. And the best part? The person who built it can't even tell you why it worked in the first place. No docs, no notes, nothing to check against. So you can't debug it, because there's nothing to debug from. You can see the cycle feeding itself. ​ Everything's crammed into one giant scenario too, obviously. One monster workflow where changing a single thing means you have to understand the entire thing first. Good luck to whoever inherits that mess. ​ Credentials? Half the time the API keys are just sitting there in plain config like that's totally normal. Some of these folks genuinely don't know a secrets manager exists. ​ And documentation, my god. There's never any. No comments, no README, not one line anywhere explaining why this thing exists or what it's even for. It's just an artifact floating in the void with no memory and no parents. ​ But here's the part nobody, and I mean nobody, ever talks about. Governance. ​ Every automation conversation is about the build. The tools, the triggers, the logic, the shiny result at the end. Fair enough, that's the fun part. But not one person stops to ask what happens after it's live. Who owns this thing? Who gets the call at 2am when it breaks? What happens when the guy who built it leaves? How do you change one piece without quietly blowing up everything attached to it downstream? That's governance, and it gets skipped every single time, because it's boring. It feels like paperwork instead of building. So the automation goes live, hums along beautifully for three months, and then someone "just tweaks one little thing," and the whole system starts misfiring so quietly that nobody even notices until it's a genuine disaster. ​ Look, I'm not telling you not to learn this stuff. Learn all of it, seriously. But if you're automating an actual business process, these are the things that decide whether it survives five minutes of contact with reality. And if you're hiring someone to do it for you, just listen to how they talk. The real ones don't only ask you how you do something. They ask why you do it, and who it affects when it changes. If the entire conversation is only ever about the how, I'd start asking some pretty hard questions about whatever they're about to hand you. ​