Hiring an automation consultant is a strange kind of purchase. You're paying someone to build something you don't fully understand, based on a call and maybe a portfolio link. Most of what makes a workflow good or bad is invisible until it breaks, so you're really hiring on trust, not on what you can inspect yourself.
I build these systems for a living, so this isn't a neutral list. But it's also exactly what I'd want to know if I were the one hiring, and it's how I structure my own work because I'd rather lose a client to these standards than keep one who never asked.
What actually separates a good automation build from a bad one
Three things, in practice.
Who owns it when it's done. Some setups run inside the consultant's own account, on their own infrastructure, under their own subscription. That means if you ever stop working with them, your automation stops too. A build that's actually yours runs in your own n8n instance, your own accounts, your own credentials. You should be able to fire the person who built it and keep everything running.
Whether the price can move. A lot of automation work is quoted loosely and then grows: "just one more integration," "a small adjustment," each one billed separately. That's not necessarily dishonest, but it means you don't actually know what you're paying until the project is over. A fixed price, agreed before work starts, forces the scope to be defined properly upfront instead of discovered as you go.
What happens after delivery. Automations aren't static. APIs change, volumes grow, edge cases show up that nobody thought of in week one. If "done" means the person disappears the moment it works, you're on your own for all of that. A defined support window after delivery tells you whether they're building something that has to keep working, or just something that has to work once, in the demo.
Questions worth asking before you hire anyone
"Will I own the workflows and the infrastructure they run on?" If the answer is vague, or involves staying on their platform indefinitely, that's the answer.
"Is the price fixed, or does it depend on how the project goes?" Fixed price means they've thought through the scope. Open-ended pricing means you're both finding out together, on your budget.
"Can I see a real workflow you've built, not just a case study?" A case study is marketing. An actual n8n workflow, even a redacted screenshot of one, tells you how they think: how they handle errors, how they name things, whether it's held together with duct tape or actually built to run unattended.
"What happens if something breaks in three months?" Get a specific answer. "I'll help you out" is not a specific answer. A support period with a real end date is.
"Who is actually building this?" On a lot of automation projects, the person you talk to during the sales call isn't the person who ends up building it. Neither is necessarily wrong, but you should know which one you're getting, because it changes how much gets lost in translation.
"Do I need to keep paying you every month, or is this a one-time build?" Some things genuinely need ongoing maintenance. A lot don't. Be suspicious of anyone whose business model requires you to never actually finish.
What this looks like on my end
I build fixed-price, scoped to your business, in your own accounts, and you own everything when I hand it over. Every package includes a support window after delivery specifically so you're not stuck the moment something changes. No subscription required to keep what you paid for.
If you want to see what that looks like for your situation, book a free discovery call and I'll walk you through it honestly, including telling you if automation isn't actually what you need yet.