n8n is good, the self-hosted version is free, and that combination is exactly why so many DIY automations end up abandoned. The software is the cheap part. n8n’s Community Edition runs on your own server at no cost, with unlimited workflows and access to well over 1,800 integrations. What costs you is everything after the build: the integration that breaks at 2am, the API key that expires on a Friday, the upstream process someone changes without telling you. That’s the real decision in front of you, and it isn’t “which tool.” It’s who owns the thing once it’s running.
Here’s the honest version most automation agencies won’t lead with: a lot of you should just build it yourself. If you’ve got one engineer who enjoys plumbing and a workflow that almost never changes, n8n is a great afternoon. We’d rather tell you that than sell you a build you didn’t need. The slice that should call us is narrower and more specific, and we’ll draw the line clearly below.
We’re gmware, a software development firm headquartered at 5900 Balcones Drive in Austin, TX, with engineering centers in Bangalore and Mohali, India. We build and run automation for companies that need it to actually keep working, and we run production data systems ourselves (our Shield Suite product covers retail intelligence across 60,000+ beverage-alcohol storefronts), so the “what breaks in production” section here isn’t theory. This post is the fork: when DIY n8n is the right call, when a built-and-managed automation pays for itself, and how to tell which one you are.
n8n, in three numbers
What is n8n, and why is everyone suddenly using it
n8n is a workflow automation platform. You wire together “nodes” (a form, a CRM, a spreadsheet, an AI model, a Slack channel) and it passes data between them when something triggers. Think of it as the connective tissue between apps that don’t talk to each other natively. A lead hits your website form, n8n catches it, enriches it, drops it in your CRM, and pings the rep. No human copies anything.
Two things make it spread fast. First, the self-hosted Community Edition is free: you run it on a small server and pay nothing for the software, with no cap on workflows. Second, it’s developer-friendly in a way most no-code tools aren’t. You can drop into raw code when the visual nodes run out of road, which is the exact moment cheaper tools leave you stuck.
The license matters, so read this before you build a business on it. n8n is fair-code under the Sustainable Use License, not traditional open source. In plain terms: you can self-host it free for your own internal operations, read and change the source, and run as much as your server handles. What you can’t do is embed n8n to power a feature you then resell or offer as a hosted service to other people without a separate license. Automating your own company? You’re fine. Reselling it as your product? Different conversation.
How much does n8n actually cost
Less than you’d guess, which is part of the trap. The pricing splits clean: free if you self-host, or n8n Cloud if you want them to run it. Cloud bills per workflow execution, where one execution is a single run of the whole workflow regardless of how many steps it contains. That’s a friendlier model than the per-step pricing some competitors use, because a 40-step workflow and a 3-step workflow both count as one run.
n8n Cloud, by execution volume
So the sticker price reads like a rounding error. A self-hosted box runs a few dollars a month. Even Cloud’s Starter is 20€. The number that never shows up on the pricing page is the one that decides this whole question: the cost of keeping it alive. That’s engineer hours, not dollars, and it’s the line item DIY budgets always forget.
The number nobody puts on the pricing page
Here’s an opinion we’ll defend: the price of n8n is irrelevant to your decision. The real cost is maintenance, and it’s invisible until something breaks. An automation isn’t a building you finish. It’s a garden. The systems it touches keep moving underneath it: an API version gets deprecated, a vendor renames a field, an OAuth token expires, a teammate edits the upstream form and the whole flow goes quiet without a single error popping up where you’d see it.
This is not a hypothetical failure mode. It’s the dominant one. Gartner found that nearly 50% of RPA projects fail to scale because rigid automations can’t handle real-world process changes. The build was never the hard part. The hard part is the boring, ongoing work of catching failures, fixing credentials, and updating the flow every time the business shifts shape around it. A demo that works on Tuesday tells you nothing about Saturday.
The low-code wave makes this worse before it makes it better. Gartner expects 70% of new applications to use low-code or no-code tools by 2025, up from under 25% in 2020, and 80% of low-code users to come from outside IT by 2026. Translation: a lot of business-side people are about to build a lot of automations that nobody in engineering knows exist. Some of those are brilliant. Some become load-bearing without anyone deciding they should be, and then someone leaves, and the thing that quietly runs payroll prep breaks with no owner and no documentation. That’s not a tooling problem. It’s an ownership problem.
You should DIY in n8n if… / call us if…
This is the whole post in one box. Read down the left column. If you’re mostly on the left, build it yourself and don’t pay anyone. If you’re mostly on the right, the math usually flips toward having it built and run for you. Most companies are split, which is fine: do the easy ones in-house, get help on the two or three that actually matter.
| Build it yourself in n8n if… | Call us if… |
|---|---|
| The workflow is low-stakes (an internal notification, a tidy data sync) | It touches money, customer data, or anything compliance cares about |
| The steps rarely change once they’re set | The upstream process shifts often and the automation has to keep up |
| It connects one or two stable systems with clean APIs | It spans five brittle systems and a legacy app nobody wants to log into |
| You have an engineer who enjoys this and will own it after launch | Nobody has time to be paged when it breaks at 2am |
| If it fails silently for a week, you’d notice and shrug | If it fails silently for a day, you lose revenue or trust |
| You want to learn the tool and have the slack to tinker | You need it working now and reliable, not a learning project |
| One person can hold the whole thing in their head | It’s becoming infrastructure several teams quietly depend on |
Which side of the fork are you on
We mean the left column honestly. We turn down small automation builds regularly, because if the whole thing is one webhook into a spreadsheet, you do not need us and paying us would be silly. The “call us” column isn’t a bigger version of the left one. It’s a different job: the job of keeping a thing alive that the business has come to depend on.
When DIY is genuinely the right call
Plenty of the time. If your finance lead wants new Stripe payments to drop a row into a Google Sheet and ping a Slack channel, that’s a thirty-minute n8n build and it’ll run for years untouched because none of those systems is going anywhere. Build it. Learn the tool. It’s a good skill to have on the team.
DIY wins when three things line up: the workflow is stable, the blast radius of a failure is small, and someone on staff will actually own it. That last one is the quiet killer. A workflow with no owner isn’t automated, it’s abandoned with extra steps. If the person who built it leaves and nobody else can open the hood, you’ve traded a manual process for a black box that will eventually fail in a way no one can diagnose. Before you build, name the owner. If you can’t, that’s your signal the workflow belongs in the “call us” column, or doesn’t belong automated yet at all.
The upside of DIY is real and worth saying plainly: you keep the knowledge in-house, you can change things instantly without a ticket, and you pay nothing but server costs. For the right workflow, that’s the correct answer and we’ll be the first to say so. Our whole view on what to automate first is built on picking the workflows that earn their keep, and a chunk of those you can absolutely run yourself.
When having it built and run pays for itself
The math flips when the automation stops being a convenience and starts being infrastructure. A flow that books revenue, touches PHI or payment data, or sits in the critical path of how customers get served is not a place to learn n8n on the job. When it breaks, and brittle integrations always break eventually, the cost isn’t the fix. It’s the hours it was down, the data that drifted, the trust you spent.
There’s also a real difference between RPA-style brittleness and automation that handles variation, and choosing wrong is expensive. We get into that in our breakdown of RPA versus AI agents: rule-based flows are cheap and predictable until the input changes shape, at which point they shatter. Knowing which approach fits which process is the kind of judgment that separates an automation that lasts from one that becomes next quarter’s incident.
The honest pitch for done-for-you isn’t “we build better workflows.” Anyone can build the happy path. It’s that we build the unglamorous 70%: the error handling, the retries, the alerting when something fails, the monitoring that tells you before your customer does, and the documentation so it isn’t trapped in one person’s head. Then we stay on call when the upstream world changes, because it will. That’s what our operations and process management practice actually does, and it’s the part DIY almost always skips until it hurts.
How to decide in one afternoon
You don’t need a committee for this. Take your list of “things we keep doing by hand” and run each through three questions. What happens if this fails silently for a day? Who fixes it when it breaks? How often does the process behind it change? Score each workflow, and the sort almost does itself.
Sort your automations in four steps
The stakes behind the exercise are not small. Over 40% of workers spend at least a quarter of their work week on manual, repetitive tasks, and nearly 60% believe they could save six or more hours a week if those tasks were automated. There’s a reason the workflow automation market is tracking around $26 billion in 2026. The opportunity is genuine. The failure mode is just as genuine: a pile of half-finished automations that nobody owns and that break the week your one builder takes vacation.
How gmware builds and runs n8n automation
When you do hand a workflow to us, we treat it as software, not a side project. We map the process first, then build it with the boring parts included from day one: error handling, retries, alerting, and monitoring, so a failure pages us instead of surprising you. We document it so it’s never locked in one person’s head. And we run it from Austin with engineering in Bangalore and Mohali, which keeps senior eyes on it during US hours without US-only burn rates. Our intelligent process automation practice is built for exactly this: automation that’s meant to keep working, not just demo well.
And sometimes we’ll tell you to build it yourself. If your workflow is one stable hop between two systems with clean APIs and someone on your team who’ll own it, you don’t need a vendor, you need an afternoon and the free Community Edition. We say that out loud because the buyers worth having are the ones who trust us to tell them when not to spend.
Tell us what you’re trying to automate and whether anyone on your side can own it after launch, and we’ll give you a straight answer on whether it’s a DIY job or a built-and-run one, scope and cost included, within 48 hours.