What actually determines the cost of an automation project

The most common question in a first conversation is "roughly what would this cost?" and the most common disappointment is that the honest answer starts with a question rather than a number.

It is not evasion. The same one-line description routinely covers projects that differ by a factor of five, and the factors that separate them are almost never mentioned in the original request.

This article is those factors. If you can answer them for your own process, you can estimate roughly where you will land before you speak to anyone — and you will spot the ones that are making your project unnecessarily expensive.

Factor 1: How many systems it touches

This is the biggest single driver, and it is not linear.

One system is usually straightforward. Read from it, do something, write back. One set of credentials, one data model, one place to test.

Two systems is the common case and the point at which a project becomes real work. Data must be translated between two models that were designed by different people for different purposes. Your customer record has fields theirs does not, and vice versa. Something has to decide what maps to what, and what happens when a field has no equivalent.

Three or more grows faster than the count suggests, because the connections multiply and so does the failure surface. Every system is one more thing that can be down, change its API, or expire your credentials.

There is also a hidden cost in getting access. Obtaining API credentials with the right permissions across several systems, in a business where different vendors administer different tools, can take weeks of calendar time even though it is almost no work. Start this before you need it; it is the most common cause of a project sitting idle.

Factor 2: Whether the APIs exist and are usable

Not all integrations are equal, and the gap is large.

Documented modern API. Clear reference, sensible authentication, predictable errors, a sandbox to test against. Fast and cheap.

API exists but is awkward. Poor documentation, unusual authentication, inconsistent behaviour, no test environment. Everything takes longer because everything must be discovered by experiment.

Data export only. No API, but you can get a scheduled file out. Workable and often perfectly fine, but it means batch rather than real-time, and you inherit a new set of questions about ordering, duplicates and late-arriving data.

Nothing. No API, no export. Now you are looking at unsupported approaches that are fragile, break on vendor updates, and may violate terms of service. Our honest advice here is usually to change the approach — or the tool — rather than build on sand.

One warning worth repeating: an API existing is not the same as an API being available to you. Some vendors gate integration access behind a higher plan. Check your plan before scoping, because "we need to upgrade first" changes the budget in a way nobody expects.

Factor 3: How messy the input is

If your automation reads documents, forms or free text, input quality dominates everything else.

One consistent format — same supplier, same layout every time — is close to a solved problem.

A handful of known formats is manageable. You handle each, plus a fallback for anything unrecognised.

Open-ended formats — anything a customer might send — is a genuinely different project. This is where AI extraction earns its place, and it comes with the validation, confidence thresholds and review queue that the exception-handling article covers. That machinery is a real part of the cost.

Scans and handwriting add another layer again, with accuracy that depends on scan quality in ways you cannot control.

The practical move: before scoping, collect twenty real inputs from the last month and count the distinct formats. People almost always guess low. If the real number is four, you have a small project. If it is nineteen, you have a different one, and knowing that early saves a painful conversation later.

Factor 4: How much human review you need

This one is counter-intuitive, because more oversight costs more to build rather than less.

Fully automatic is cheapest to build. No interface, no queue, no permissions. It suits processes where errors are cheap and visible.

Exception review — most items pass, unusual ones go to a person — is the common middle ground. It needs a queue, a way to see why something was flagged, and a way to correct and resume. That is a small application in its own right.

Approve everything means the automation prepares and a person confirms each item. Appropriate for financial or legal steps. It needs the most interface work and it caps your time saving, though preparing-for-approval still removes most of the effort.

Worth saying plainly: the review interface is frequently a larger piece of work than the automation it supports. It is not waste. It is the part that lets people trust the system, and skipping it is how you end up with an automation nobody uses.

Factor 5: Where it runs, and who keeps it running

Managed cloud is usually cheapest and quickest. Someone else handles the servers.

Your existing cloud account is fine and often preferred for data governance, with a little extra setup and coordination.

Your own servers, or an air-gapped environment, is the most expensive option: deployment is harder, iteration is slower, and access for support has to be arranged.

Then there is the question people forget: after handover, who fixes it when it breaks? If you have technical staff, handover can be documentation and a walkthrough. If you do not, you need an arrangement — otherwise the first credential expiry becomes a crisis, and the automation becomes shelfware.

The costs that are not development

These are separate, recurring, and charged by third parties. They should appear as their own line, not buried in a single figure.

Model usage is the one that surprises people, because it scales with volume in a way development does not. Processing three hundred documents a month and processing thirty thousand are different monthly bills even though the build is identical. If your volume might grow substantially, ask for the per-unit figure rather than a monthly estimate — that is the number that lets you forecast.

What makes a project cheaper

From the same set of factors, in rough order of impact:

Narrow the scope. One workflow, one document type, one integration. You can extend later, and you will extend with better information.

Reduce format variety at the source. If you can ask three suppliers to send a consistent format, that is worth more than any amount of clever parsing.

Accept batch instead of real-time, if the business genuinely does not need real-time. Scheduled processing is simpler, cheaper, and easier to reason about.

Sort out access early. Credentials arranged before kick-off removes the most common source of dead time.

Write the process down yourself. An afternoon of your time replaces several hours of discovery — at consulting rates.

Decide the exception rules before the build. Skip, hold or stop; who reviews; what counts as done. Deciding these mid-build is where change requests come from.

What makes it more expensive, and is sometimes still right

Not every cost is waste. These are legitimately worth paying for when the process warrants it:

• A proper audit trail, when you are regulated or handling money.
• Real-time processing, when the business genuinely depends on it.
• A good review interface, when a person must be in the loop repeatedly — this pays back in adoption.
• Handling every edge case, when missing one is expensive.

The mistake is paying for these by default. The right question is not "can we have it?" but "what happens if we do not?"

How to get an accurate quote

Bring these and the conversation converges quickly:

1. The process written down as steps, in order.
2. Twenty real inputs from the last month, with the format count.
3. Every system it touches, and what access you can actually obtain.
4. The decision points, with a named owner for each.
5. Your expected volume now, and your guess for a year out.
6. Where it must run, and any data constraints.

With that, most scoping conversations produce a defensible range inside an hour. Without it, any number you are given is a guess, and guesses in this field tend to be wrong in the direction that is discovered late.

If you want a number for your specific case, bring that list to a free consultation. And if the honest answer is that a scheduled export or a setting in software you already own would do it, we will tell you that instead.