I’ve been on the hired side of exactly this stack (CRM syncs, lead routing, AI agents in production), so here’s the bar I’d set — phrased as questions you can ask in a 20-minute call. The answers separate people fast.
1. “What happens when the third-party API is down for two hours?”
Weak answer: “n8n retries.” Strong answer: they tell you where the item waits, how it comes back, and how you find out it happened. Anyone who has run automation in production has an opinion about dead-letter queues, even if they don’t use the phrase.
2. “How do you stop the same webhook from being processed twice?”
This is the single best filter I know. Providers retry — retries are normal. If they don’t immediately reach for an idempotency key, or describe storing the event id before doing the work, their workflows quietly double-charge, double-message, and inflate every report you will ever read. Ask for a story, not a definition.
3. “Show me a node that runs once per item versus once per execution.”
An HTTP node in an item context runs once per item. I once had a workflow download the same CSV 744 times because of exactly that. Anyone who has been burned will mention executeOnce without prompting.
4. “Where does business logic live?”
If the answer is “in the AI prompt,” that’s your risk. Rules that cost money — discounts, eligibility, pricing — belong in a Code node or a database lookup, not in a prompt. I learned this when a prompt-only rule gave a discount because a customer simply insisted. Prompts persuade; they don’t enforce.
5. “How will I know when a workflow stops working?”
The honest default is that nobody notices for days. A good hire builds the watchdog early — something that runs every 15 minutes, alerts when the last successful execution is too old, and de-duplicates so it doesn’t spam you into ignoring it. Uptime doesn’t come from the workflow; it comes from the thing watching the workflow.
6. “Walk me through getting a change into production.”
Environments, credential handling, what a rollback looks like, and what happens to in-flight executions during a deploy.
On your specific questions:
Portfolio vs community contributions. Community badges are weak signal. A screen recording of a workflow running on real data is strong signal — especially the failure path. Ask to see something break and recover, not the happy path. Custom node development is nice but rarely what you actually need; most real problems are architecture, not missing nodes.
Scoping. Yes — a paid discovery/audit is worth it. Short, fixed price, and you get a written map of the flows, the data model and the failure points. It does two things: you learn whether you can work with the person before committing to months, and if you part ways you keep the map. That beats an estimate written blind on the exploratory half.
Build + maintain. Separate them explicitly. Build is a project with acceptance criteria per milestone. Maintain is a monthly retainer with a defined response window. Bundling the two is how both sides end up resentful.
Platforms vs direct. Upwork feels like a lottery because you’re buying a proposal, not a person. Here or referrals works better precisely because you can read how someone answers a technical question in public before you ever pay them — which is roughly what this thread is doing for you already.
One last flag worth more than any of the above: ask who owns the accounts. Credentials, API keys and the server should be in your name from day one, with the developer added as a collaborator. If someone resists that, you’ve learned what the relationship would be like.
