How to hire an n8n expert (and how to tell a good one from an expensive one)

Hiring someone to automate part of your business is strange. You are paying for something you cannot inspect. The workflow either works or it does not, and by the time you find out it did not, the invoice is already paid and the person is gone.

I build n8n automations for a living, in Belgium, and a real part of my work is fixing systems someone else delivered. Same story every time: it demoed beautifully, then it quietly broke, and nobody could tell why. So this is the guide I wish my clients had read before they hired the first person. Some of it will cost me work. That is fine.

First: are you sure you need one?

Be honest about the size of the problem. If you want a form to drop into a spreadsheet and email you, that is an afternoon of your own time and a free tutorial. Hiring someone for that is a waste of your money.

You want help when at least one of these is true:

• The process touches money, customers or legal deadlines, so a silent failure actually costs you.
• It spans several systems that each have their own quirks, and one of them is slow or unreliable.
• You built something yourself and it works, but you are afraid to touch it.
• The person who will use it every day is not the person who would build it.

If none of those apply, save your budget. A good automation person will tell you this themselves. That is the first thing to look for.

The questions that actually tell you something

You do not need to understand n8n to judge the answers. You need to listen for whether they think about the boring parts.

1. What happens when it fails?

This is the question. Everything works on a good day. Ask what happens when the API is down, when a record is missing a field, when the same trigger fires twice.

A weak answer is a shrug, or "it will just run again next time." A strong answer talks about error workflows that alert someone, about retries, about making sure a job that runs twice does not send two invoices. If they have never thought about the failure path, you are buying a demo.

2. Where does the workflow keep track of what it already did?

n8n has no memory between runs. If a build depends on remembering something, that memory has to live somewhere outside the workflow, in a database, a table, a status field.

Someone who builds reliable systems will answer this instantly, because it is the backbone of how they work. Someone who does not understand it will build something that duplicates records, reposts the same thing, or double-charges a client the day something hiccups.

3. What happens to my API keys?

Ask where your credentials will live. The right answer is that they go into n8n's credential store, encrypted, and never get typed into a node or pasted into a shared file. I have opened workflow exports from other builders with a live API key sitting in plain text inside them. That file gets emailed around, screenshotted, committed to git. It is a real risk and it is entirely avoidable.

4. Can the person who uses this every day understand it?

Automation that only its builder understands is a liability wearing a disguise. Ask how someone on your team pauses a job, retries a failed one, or fixes a typo, without opening n8n at all.

The best builds are boring here on purpose. Someone changes a status in a table from Ready back to Draft and the system behaves. No code, no panic, no phone call to the freelancer.

5. What do I get when we are done?

You should get the workflow file, documentation a normal person can read, and the accounts in your own name. Not their Opus account, not their Airtable base, not their server. If any part of the system lives in someone else's account, you do not own it. You are renting it, and the rent goes up the day you want to leave.

Warning signs

• They say yes to everything. Some processes should not be automated, usually because they change too often or because the exceptions are the actual job. A good builder says so.
• They only show screenshots. Anyone can arrange nodes on a canvas. Ask to see something running, and ask what broke while they were building it. Everyone has a story. People who claim they do not have not shipped much.
• They talk about tools instead of your process. If the second sentence is about AI agents and vector databases before they have asked how your business actually works, you are buying their hobby.
• No documentation in the quote. A build without docs is cheaper for a reason. You pay the difference later, with interest, usually while they are on holiday.
• They are cheap and fast. An automation that half works is worse than none, because you stop checking.

What it should cost

I will not pretend there is one number. It depends on how many systems are involved, how messy your data is, and how much the process matters. But two rules of thumb hold up.

Compare it to the hours it saves, not to a tool subscription. If a process eats five hours a week and never gets done properly anyway, the automation pays for itself fast. If it eats twenty minutes a month, do not automate it at all.

Be suspicious of both ends. Very cheap usually means no error handling and no docs, which is the part you are actually paying for. Very expensive is often a big agency putting a junior on it. What you want is someone who has run these systems in production themselves and can show you what broke.

Local or remote?

Honestly, for this kind of work it barely matters. n8n builds are done remotely, and a video call is enough. Where being local does help, which is the reason clients in Belgium tend to look for someone nearby: you are in the same timezone, you can meet if the project is big enough, and there is no confusion about invoicing, VAT, or which rules apply to the data you are moving around.

If you are handling personal data of EU customers, do ask where your n8n instance runs and who can reach it. Someone who cannot answer that quickly has not thought about it.

A quick checklist

Before you sign anything, make sure you can answer yes to all of these:

• They asked about my process before talking about tools.
• They can explain what happens when it fails.
• My API keys will live in credentials, not in a file.
• Someone on my team can operate it without opening n8n.
• Documentation is part of the deal, not an upsell.
• Every account is in my name.
• They told me at least one thing not to automate.

Where I fit in

I am Wout, an n8n consultant based in Belgium. Everything above is how I work, and it is also how I judge the workflows I get asked to rescue. If you want to see the patterns before you talk to anyone, the rest of this knowledge base lays them out, including the status-driven pattern from question two and the seven mistakes I see in almost every workflow I inherit.

If you would rather just tell someone what eats your time, my Dutch page for Belgian clients is here, or you can email me directly. One paragraph is enough. I reply with an honest take, including when the answer is that you do not need me.