What the build costs with me is written openly on the automations service page. I am not repeating those numbers here, because they can change and an article never notices. The interesting part is the one that appears in no quote anyway.
An automation has four cost items: the build, the platform, the compute for any AI steps and the upkeep. The first is the only one anybody discusses beforehand, and depending on the workflow it is not even the largest after two years.
Item 1: the build
The build is the number in the quote, and it varies more than most people expect. Three things drive it, and you can assess all three yourself before anyone sends you anything.
- How many systems are involved. Two tools with proper interfaces are a different job from four, one of which only knows how to export a file. Every additional connection brings its own failure cases with it.
- How clean your data is. If the same company is spelled three different ways in three systems, the first week goes into tidying up. That is not automation work, but the automation does not function without it.
- How many exceptions there are. The normal case is quick to build. The time goes into the exceptions: a missing address, a duplicate request, or a tool that simply does not answer.
If somebody quotes you a price without having asked about those three points, the number is a guess. It will either be exceeded later or it came with a buffer built in, and you are the one paying for that buffer.
Item 2: the platform, every month
Every automation runs somewhere, and that somewhere costs money. How much depends less on the vendor than on what it counts: for some, every single step is one unit, for others the whole run. I worked through what that difference does in n8n, Make or Zapier.
For a rough estimate one simple rule is enough. Multiply the number of runs per month by the number of steps, and you have the order of magnitude you are operating in with most vendors. At a few hundred runs this is an amount nobody notices, and from a few thousand upwards it becomes the item that dominates the entire calculation.
The alternative is your own server, where nothing is counted per transaction. That costs a fixed amount per month plus attention: updates, backups and somebody who notices when nothing runs overnight. So this calculation does not tip in your favour by itself, but only above a certain volume.
Item 3: the AI steps
As soon as a language model sits inside the workflow, an item appears that did not exist three years ago. It is billed by volume of text, and in both directions, so for what you put in and for what comes back out.
Per transaction those are fractions of a cent, which sounds harmless and is therefore happily ignored. The amount becomes relevant because it grows with volume and because it quietly doubles the moment somebody adds a second model call to the workflow. Work it out once for your volume before anything gets built, and then again once that volume has grown tenfold.
Not every step needs the largest model. Sorting a text into a category and drafting a letter to a customer are tasks of different weight. Using the same model for both means paying a multiple on the easy step for no return.
Item 4: the upkeep, which everybody forgets
An automation is not a piece of furniture you put down once. It hangs off other people's systems, and those change without asking you. An interface gets a new version, a tool renames a field, an access token expires. Suddenly the workflow stops or, worse, keeps running and writes nonsense.
The effort involved is smaller than many people fear, but it is not zero. As a rule of thumb I budget 2 to 4 hours a year per workflow once it runs stably. In the first year it is double that, because the fine tuning still happens there. What that work actually consists of is described on the page about operations and support.
Those hours occur whether you buy them in or somebody on your team absorbs them. The only difference is whether they show up on an invoice or disappear invisibly into an afternoon that somebody had planned to spend on something else.
The calculation that actually matters
Costs on their own say nothing as long as the saving next to them is missing. The real question is therefore not what an automation costs, but after how many months it has paid for itself. That takes four numbers, and you already know all four.
How often does the task happen?
Count one typical week and extrapolate. Gut estimates are regularly off by a factor of 2 here, in both directions.
How long does it take by hand?
Actually time it once instead of guessing. And count the searching and the asking around, because in most workflows that is half of the time.
What does that hour cost you internally?
Not the hourly wage, but the full cost including overheads and downtime. In most companies the figure sits well above what appears on a payslip.
How much of it really goes away?
Rarely all of it. Work with 70 percent rather than 100, because exceptions keep being handled by hand and somebody looks in now and then.
An example with round numbers: the task happens 80 times a month and takes 8 minutes by hand, so a good 10 hours. At 40 euros of internal hourly cost that is 400 euros a month, and since 70 percent falls away, 280 euros of saving remain. Platform and model take 40 euros of that, leaving 240 euros. At 1,500 euros for the build, the break-even point arrives after a good 6 months. That is only an example calculation, but the structure behind it stays the same.
An automation that only pays for itself after two years does not pay for itself. No workflow stays unchanged that long.
My own threshold sits at 12 months. Anything that pays for itself within a year is a good investment, because a workflow can be surveyed that far ahead. If an automation needs 3 years, I turn it down in the initial call, because one of the tools involved will have been replaced by then.
Three items that tip a good calculation over
The example above works out as long as nothing gets in the way. In practice one of these three things regularly gets in the way, and none of them appears in a quote.
- Running both ways during the changeover. For a few weeks the old route keeps running alongside, because nobody trusts the new one straight away. That is the right instinct, but it costs time that appears in no savings calculation.
- Getting the team up to speed. A workflow nobody understands gets worked around. An hour of introduction and a page of documentation are not a luxury, but the difference between a thing being used and a thing being ignored.
- The change after three months. Once the workflow runs, it becomes obvious what else it should be able to do. That is a good sign, but budget for it as an item rather than being surprised by it.
What you can do to make it cost less
The biggest lever is not with the vendor but with you, and it applies before the quote. Four things reduce the effort noticeably, and all four cost you nothing but thinking.
Settle the workflow before automating it
If three people do the task differently, that question gets resolved first and the building happens afterwards. Otherwise you automate one of the three variants and the other two people are annoyed.
Start with one workflow, not five
The first is always the most expensive, because the access, the error handling and the notifications all get built along the way. The ones that follow reuse that work and cost considerably less.
Tidy your data beforehand
Duplicate entries and inconsistent spellings cost real hours inside the project. You can do this work yourself, and nobody knows your data better than you.
Leave the exceptions out on purpose
Automating 80 percent of cases is often half the price of automating 100 percent. The remaining 20 percent are allowed to keep landing on somebody's desk.
And if you do not yet know which workflow comes first, that decision carries more weight than any negotiation over price. It is covered at length in which tasks to automate first.
If the arithmetic shows that the workflow needs an interface, or that somebody has to keep looking into it, the cost question is a different one. At that point it is no longer about an automation but about buying or building, and a separate calculation applies there.
- An automation has four cost items: build, platform, AI steps and upkeep. Only the first one appears in the quote.
- The platform cost grows with runs times steps. At a few hundred runs it is irrelevant, and from a few thousand it dominates the calculation.
- Budget 2 to 4 hours of upkeep per workflow per year, and double that in the first year. Those hours occur whether you buy them in or not.
- The saving is rarely 100 percent. Working with 70 percent comes considerably closer to reality.
- Anything that pays for itself within 12 months is worth doing. Anything needing 3 years will not survive that long anyway.
- The biggest lever sits before the quote: a settled workflow, clean data and exceptions left out on purpose.
Common questions
Why will nobody name a fixed price before knowing the workflow?
Because the effort hangs almost entirely on things that are invisible from outside: the number of systems involved, the state of the data and the exceptions. A number without that knowledge is either a guess or contains a buffer you end up paying for. After an initial call a fixed price is perfectly possible, and that is exactly how I do it.
What does running it cost per month?
It consists of two parts: the platform and model costs, which depend on your volume, and the support, which depends on the number of workflows and how critical they are. The prices for support are listed on the page about operations and support. Anyone taking it on themselves still pays it, just in hours rather than in euros.
Does an automation pay off at all in a small company?
That depends on frequency and not on company size. A task happening 100 times a month pays off just as well with 4 people as with 40. The reverse holds too, because nothing that happens twice a year is worth automating in a large company either.
What happens to the costs if my volume grows sharply?
The build is paid for and stays paid for, but platform and model costs grow along with the volume. That is exactly where it is worth looking at the billing model again, because moving to another tool or your own server only pays off above a certain volume. The thresholds for that are in n8n, Make or Zapier.
Can I maintain the automation myself later on?
With simple workflows yes, and you get the access and the documentation for it. The hard part is not changing a step but spotting a silent failure, meaning the case where something keeps running and writes wrong data. Anyone wanting to take that on needs monitoring and the willingness to deal with it on an inconvenient day.
