A single n8n workflow that moves data between two apps costs from around $2k to build. A set of business-critical automations with several integrations, an AI step, and real error handling runs $5k to $15k or more, and the honest headline most agencies bury is that the build is the cheap part — the ongoing cost of keeping automations working as the APIs underneath them change is what you're actually signing up for.
So instead of one number that would be a lie, here's how the price gets assembled, what pushes it up, why automations break, and the choice that decides your real total: hand the build over once, or keep it on a retainer. Duskel builds and maintains n8n automations from $2k for a scoped one, with the bigger systems running as monthly engagements.
The cost table, honestly
n8n cost sorts cleanly into three tiers by how much can go wrong. The one-off column is what it costs to build and hand over; the retainer column is what it costs to have someone own it — monitor it, fix it when an upstream API shifts, and extend it as your process changes. Most teams need some of both.
| Workflow complexity | One-off build | Timeline | Monthly retainer |
|---|---|---|---|
| Simple — one trigger, 2–3 apps, happy path plus basic retries | from $2k | 1–2 weeks | from $500/mo |
| Medium — several workflows, multiple integrations, an AI step, error routing | $5k–$15k | 3–6 weeks | from $1.5k/mo |
| Complex — many interdependent flows, self-hosted infra, high volume, custom nodes | $15k+ | 6–12 weeks | from $3k/mo |
n8n automation cost by complexity — build vs retainer
Two honest caveats. The retainer figures assume a real workload — a monthly check-in and a few hours of fixes and small changes at the low end, active ownership of a system your business runs on at the high end; a retainer isn't a maintenance tax, it's someone on the hook when a workflow stops. And these are ranges, not quotes: the same "sync leads to the CRM" ask is a $2k afternoon or a $10k project depending entirely on the integrations behind it.
What actually drives the cost
The biggest driver is the integrations, specifically the bad ones. A workflow that touches n8n's well-supported nodes — Slack, Sheets, Postgres, the major CRMs — is fast. The cost lives in the systems that fight you: an API with brittle auth, punishing rate limits, awkward pagination, or no native node at all, so you're hand-rolling HTTP calls and parsing responses that were never meant to be consumed programmatically. One gnarly integration can cost more than the other five combined.
- Error handling and reliability. A demo workflow assumes every call succeeds. A production one assumes they'll fail — retries with backoff, an error workflow, dead-lettering the items it can't process, and alerting a human when something breaks. That hardening is often half the build, and it's exactly the half that separates an automation you can trust from one that silently drops data. We go deep on it in n8n automations that don't break at 2am.
- AI steps. If a workflow classifies, extracts, or drafts with a model, you're paying for prompt design, handling for when the model is slow or wrong, and guardrails so one bad output doesn't poison everything downstream. Cheap to prototype, real work to make dependable.
- Self-hosted vs cloud. n8n Cloud is a subscription with nothing to run — fastest to ship. Self-hosting removes per-execution limits and keeps your data in-house, but now someone owns the server, updates, backups, and uptime. That's a real ongoing cost, and it's usually why a complex build sits in a retainer rather than a hand-off.
- Volume and idempotency. A workflow firing a few times a day is forgiving. One processing thousands of items an hour needs deduplication, idempotency keys so a retry can't double-charge or double-send, and batching — engineering the low-volume version never needs.
Why automations break — and why a retainer isn't upselling
An n8n workflow is not a build-once asset like a landing page. It sits on top of other people's software, and that software changes without asking you. An API deprecates a field, a vendor tightens a rate limit, an auth token expires, a login flow adds a step, a service returns a new error shape your workflow never expected. The automation didn't rot — the ground under it moved. This is the single most misunderstood thing about buying automation: the fragility is structural, not a sign someone built it badly.
That's why a retainer exists, and it's not an upsell. Either you keep the ability in-house to notice a broken workflow and fix it fast, or you pay someone to be on the hook for that. What you can't do is buy a business-critical automation, wave goodbye to whoever built it, and expect it to still work in a year. When it breaks at 2am, the question that matters isn't "how well was it built" — it's "who's responsible for fixing it," and if the answer is nobody, you've already lost the orders.
Build once vs managed — which one you actually want
The real decision isn't the price tier, it's the ownership model. Some automations genuinely should be built and handed over. Others will cost you far more in silent failures than a retainer ever would. Here's the honest comparison.
| Build once, hand over | Managed retainer | |
|---|---|---|
| Best for | Low-stakes, internal, or short-lived automations; teams with an engineer who can maintain it | Anything a business function depends on, or touching flaky third-party APIs |
| When an API changes | You notice (or don't), then find someone to fix it | We're already monitoring; it's caught and fixed under the retainer |
| Cost shape | One-off, then $0 — until something breaks | Predictable monthly, no surprise emergency invoices |
| Silent-failure risk | High — nobody's watching for the quiet ones | Low — heartbeat and error alerting is part of it |
| New requirements | A fresh quote and scheduling each time | Rolled into the ongoing engagement |
Build once and hand over vs managed retainer
Our honest steer: build-and-handover is the right call for the genuinely simple, low-stakes automations, and we're happy to ship those and get out of your way. The moment an automation is doing real work your business relies on, someone has to own it — whether that's your team or ours. Pretending otherwise is how a $2k build turns into a $40k mess of dropped orders nobody caught.
Who to hire — and why us
You've got three options. A freelancer on a marketplace is cheapest and fine for a one-off, low-stakes flow, but you're betting on one person's availability the day it breaks. An in-house hire only makes sense once automation is a standing part of your operation. An agency sits in between: you get people who've built the failure-handling patterns before and who are still there in six months when the API changes.
Where Duskel fits: we're a software studio that ships and maintains production systems, not just workflow diagrams. We build the error handling, dead-lettering, and alerting into the automation from the start rather than bolting it on after the first outage, and because we run our own products on this stuff, we treat your automations the way we treat ours — as something that has to keep working, not something to demo and abandon. If you're choosing an n8n platform in the first place, we wrote n8n vs Make vs Zapier to help.
If you want a real number for your own case, tell us what you're trying to automate — which apps, roughly how often, and how bad it is when it fails — and we'll scope it honestly, including whether you even need a retainer or can take the build and run.