Almost nobody answers this honestly, because the honest answer starts with "it depends" and that reads like evasion. So here is what it actually depends on, in enough detail that you can estimate your own situation before you talk to anyone.
There are three costs, and teams routinely budget for only the first.
1. Building it
The build cost is driven far less by the number of steps than by two things: how many systems are involved, and how much disagreement there is about what should happen in the exceptions.
A workflow moving data between two systems that both have good APIs, with rules everyone already agrees on, is a small piece of work — days rather than weeks. The same workflow becomes substantially more expensive when any of the following are true:
- A system has no API. You're now looking at database access, file exports, or scraping, all of which are more fragile and need more error handling.
- The rules aren't actually written down. This is the most common and most underestimated cost. "Route the lead to the right salesperson" turns out to involve six conditions that live in one person's head, and three of them contradict each other.
- The data is messy. Duplicate records, inconsistent formats and missing fields all need decisions, and each decision is a small negotiation.
- Something in the chain is slow or rate-limited. That forces queuing, batching and retry logic that a simple version wouldn't need.
Our rule of thumb: the mapping conversation — working out what really happens today, including the exceptions — regularly takes as long as building the thing. That's not wasted time. Automating a process nobody fully understands is how you get an automation that confidently does the wrong thing.
2. Running it
This is the cost people miss, and it's structural rather than incidental.
Zapier charges per task, where a task is roughly one action on one record. Costs scale with volume, which means a workflow that's cheap during a pilot can become a meaningful line item once it's carrying real load.
Make.com charges per operation, with similar volume sensitivity but generally more work done per unit.
n8n charges per workflow execution on its cloud plans — a full run counts once regardless of step count — and self-hosted, you pay for a server instead of per run.
The practical implication is worth stating plainly: on per-task pricing, your automation gets more expensive as your business grows. That's fine when the automation saves more than it costs, and it's worth modelling before you build rather than discovering it on an invoice. If you're processing thousands of records a month, the platform choice can matter more to total cost than the build did.
If AI steps are involved, add model costs. These vary enormously with how much context you send per call — the same feature can differ by an order of magnitude depending on how it's built.
3. Keeping it working
Automations decay. Not because they're badly built, but because the world around them changes: an API deprecates a version, a credential expires, someone renames a field in the CRM, a vendor changes a response format.
Budget for this explicitly. A workflow nobody owns is a workflow that will fail silently, and the cost of a silent failure is usually discovered weeks later in the form of missing data.
Practically, that means either someone on your team owns them, or you have a maintenance arrangement. Both are real costs. The one option that isn't real is assuming it will keep working unattended forever.
Is it worth automating at all?
Before cost, the more useful question. A rough test:
Multiply the time the task takes by how often it happens by the loaded cost of the person doing it. That gives you annual cost. Then ask three more things:
- How stable is the process? Automating something that will be redesigned next quarter is wasted work.
- What does an error cost? A manual process with a human sanity-checking each record has an error rate you're implicitly accepting. Automation removes the human — which is a benefit when the rules are clear and a risk when they aren't.
- Is time the real cost? Often the bigger win isn't hours saved but errors avoided, or a delay removed from a customer-facing process. Those are harder to put a number on and frequently worth more.
If the process is unstable, rare, or genuinely requires judgment on every case, the honest answer is not to automate it. We tell people this regularly, and it's usually cheaper advice than the alternative.
Where the money actually goes
For most projects we see, the split looks roughly like this:
| Cost | Typical share | Notes |
|---|---|---|
| Mapping and decisions | Often the largest single piece | Rises sharply when rules aren't documented |
| Build | Proportional to systems involved, not step count | A missing API is the big multiplier |
| Platform fees | Small at low volume, dominant at high volume | The one that surprises people later |
| Maintenance | Ongoing, frequently unbudgeted | Cheaper than silent failures |
What to do before asking for a quote
You'll get a better answer, faster, if you bring:
- The process as it actually runs, including what people do when it goes wrong
- The systems involved, and whether each has an API
- Rough volume — records per day or month
- What "done correctly" means, and what a mistake costs
That's usually enough for a realistic estimate. Without volume in particular, any number you're given is guesswork.
If you want a straight answer on what a specific process would take — including whether it's worth automating at all — tell us what it involves and we'll come back with a scoped estimate.
Related: n8n workflow automation · Make.com automation · Zapier integration · AI agents and automation