n8n Developer: What They Actually Do and How to Hire One

What the job actually is

n8n is a workflow tool where each step is a node — receive a webhook, call an API, branch on a condition, write to a database. Anyone can drag those onto a canvas within an hour, and that is genuinely most of what a simple automation needs.

What you are hiring for is the rest. A workflow that runs once in a demo and a workflow that runs four hundred times a day differ in things the canvas does not show you: what happens when an API returns a rate limit, whether a failed run retries or vanishes, where credentials live, what happens when two runs overlap on the same record, and whether anyone finds out when it breaks.

That is why the useful question in an interview is never "can you build this?" It is "what happens when this fails at 3am?" The answer separates someone who has operated n8n from someone who has assembled it.

The second half of the job is the code nodes. n8n lets you drop JavaScript or Python into a step, which is the escape hatch for anything the pre-built nodes do not cover. Developers who can use that well build things the no-code-only crowd cannot; developers who reach for it constantly are usually working around a design they should have reconsidered.

Three levels of n8n work, and which you need

Almost every mismatch between what a client wanted and what they got comes from hiring the wrong level. They are genuinely different jobs.

The builder connects existing nodes to automate a defined process — form to CRM, notification on a trigger, a scheduled report. Fast, inexpensive, and correct for most small businesses. This is the level most freelance listings describe.

The integrator handles what the pre-built nodes do not: an API with no node, awkward authentication, pagination, data that arrives in one shape and has to leave in another. They write code nodes, and they think about idempotency — whether running the same thing twice does the job twice.

The platform engineer runs n8n itself. Self-hosting, queue mode for concurrency, workers, database backing, upgrades, backups, and the monitoring that tells you a workflow died. If you are self-hosting anything business-critical, this is the level you need, and it is the one most commonly skipped.

The practical guidance: hire the builder for a scoped process on n8n Cloud, and only pay for the platform engineer once you are self-hosting or the automations are load-bearing.

The retry design, credential handling and monitoring described here are ordinary AI workflow automation work — built into the stack you already run, rather than handed over as a canvas nobody maintains.

The license question almost nobody asks

n8n is frequently described as open source. It is not, in the sense that term formally carries, and the difference has practical consequences worth knowing before you commission a build.

n8n is released under the Sustainable Use License, version 1.0 — a fair-code license rather than an OSI-approved open source one. The license file states that you may "use or modify the software only for your own internal business purposes or for non-commercial or personal use", and that you may "distribute the software or provide it to others only if you do so free of charge for non-commercial purposes".

For most businesses this changes nothing at all. Running n8n inside your own company to automate your own operations is exactly the internal business use the license permits, self-hosted or otherwise.

Where it matters is if you intend to run n8n on behalf of other people — hosting an instance your clients log into, bundling it into a product you sell, or charging for access. That is outside what the free license grants, and n8n sells separate arrangements for it. If that is your model, settle it with n8n directly before you build, not after. This is a summary of a license, not legal advice, and the terms are short enough to read yourself.

It is worth asking any prospective developer what they understand the license to allow. It is a fast test of whether they have thought past the canvas.

Self-hosted or n8n Cloud changes who you need

This decision drives the hire more than the workflows do.

n8n Cloud is the managed option. Someone else runs the servers, applies upgrades, and keeps it available. You are hiring for workflow design only, which is a smaller and cheaper job, and the right default unless something specific rules it out.

Self-hosting is chosen for three real reasons: data that cannot leave your infrastructure, volume where the managed pricing stops making sense, or an integration that needs network access to something private. All three are legitimate. What people underestimate is that self-hosting converts n8n from a subscription into a system you operate — upgrades, database, backups, and someone on the hook when the instance is down.

If you self-host without anyone owning that, the failure is predictable: it runs beautifully for months, then an upgrade or a full disk takes it out, and the automations your operations depend on stop silently. Silent is the important word.

What to ask before you hire

Six questions that surface production experience quickly.

• Show me an n8n workflow you built that is still running six months later, and tell me what broke early on.
• How do you handle a step that fails — retries, dead-letter path, or does the run just end?
• Where do credentials live, and who can see them?
• How do you stop the same record being processed twice?
• How are workflows versioned, and how do you move one from test to production?
• If this stops firing on a Saturday, how does anyone find out?

Red flags

Any one of these is worth slowing down over.

• A portfolio of screenshots rather than anything running.
• No answer on monitoring — a workflow nobody watches fails silently by design.
• Credentials pasted into code nodes rather than stored as n8n credentials.
• Proposing self-hosting for a small business with no operational reason for it.
• Describing n8n as open source without qualification, which suggests the license has never been read.
• Building only in the production instance, with no way back when a change breaks something.

When you do not need an n8n developer

Two cases where hiring one is the wrong move, and saying so up front saves everyone time.

If the process you want automated is not written down and two people do it differently, there is nothing to build yet. A developer will implement one person's version, and the other half of the team will route around it. Define the process first; that work is not technical.

If you need one or two simple connections between mainstream tools, a competent operations person can build them in n8n or anything comparable in an afternoon. Paying a specialist for that is only worth it when the cost of it being wrong is high.

The point at which a developer earns their fee is when the automation touches money, customers, or data you cannot reconstruct — which is exactly the point where the parts that are not the canvas start to matter.