Hire an AI Automation Consultant, an Engineer, or a Dev Shop?

Once an organization decides that some process should stop being done by hand, the next decision is who does the automating. There are four honest answers, and each is right for someone. The mistake is picking by habit: hiring because that is what you did last time, or calling a consultant because a consultant called you.

The four options

Do it yourself

Someone on the team learns the tools and builds it. Cheapest in cash, slowest in calendar, and the most common way automation projects stall. Without a guide, the first hard problem (an integration that needs credentials nobody has, a data field that is never clean) becomes the place the project stops.

Right when: the process is small, the tool you already own can do it, and the person has the time and the curiosity.

Hire an AI automation consultant

Someone who has done this many times scopes, builds, or guides the build. The good ones baseline before they build, teach as they go, and leave documentation. The bad ones leave a black box and a retainer. The difference is visible in how they talk about measurement and ownership before the contract is signed.

Right when: you want the result in weeks, you want your people to understand it, and the scope is one to three automations at a time.

Hire a development shop

A firm builds custom software to a specification. Strong when the thing you need has its own home: a portal, a platform, a product. Weak when the thing you need is an integration between two tools you already pay for; a dev shop will often propose rebuilding one of them.

Right when: the workflow is part of what you sell, or the volume has outgrown every off-the-shelf tool, and you have someone who can own the specification.

Hire an engineer

A full-time salary, months to ramp, and then capacity for everything. Right for a company whose product is software. Overkill for most internal automation, where the work is bursty: a month of building, then a quarter of nothing.

What each costs beyond the invoice

The invoice is the easy part. The costs that decide whether the project was worth it are these.

• Your time. Every option needs a person on your side who knows the process and can test. DIY needs the most; a dev shop needs a specification owner; a consultant needs two to four hours a week.
• Dependency. Who can change it in six months when the process shifts? If the answer is "only the people we paid," every change is a purchase order.
• Knowledge. Did anyone on your team learn how it works? Learning is the cheapest insurance against dependency.
• Measurement. Will you know what it returned? Without a baseline and a log, you will not, and neither will the person who approved the budget.

What each should cost, in shape

Prices vary too much by region and scope to quote here, but the shape of the price tells you a great deal about the relationship you are entering.

A consultant should quote a fixed fee for scoping and a fixed fee or a short monthly rate for the build, with the baseline named in the scope. An hourly rate with no ceiling means the incentive runs the wrong way: the longer it takes, the more they earn.

A dev shop should quote a fixed build fee against a written specification, then a separate monthly figure for hosting and support. Be wary of a low build fee paired with a vague support contract; the support contract is where the money is made, and where your dependency lives.

An engineer costs a salary plus benefits plus the months before they are productive, and then costs that every month whether there is work or not. For a company that is not a software company, that is the most expensive option per automation by a wide margin, and it only makes sense when the backlog is deep enough to fill a year.

Doing it yourself costs the time of the person doing it, valued at their loaded rate, plus the cost of the project stalling. That second number is usually larger than the first, and it never shows up on an invoice.

Whatever the shape, insist on one thing in writing: a baseline before the build and a ledger after it. If the seller will not commit to measuring the result, the price is a guess about a guess.

Questions to ask any of them

A consultant, shop, or candidate who answers all five plainly is worth talking to. One who changes the subject to the technology is selling the technology.

A fifth option: build the capability

The four options above assume automation is a project. For organizations with more than a handful of processes worth automating, it is closer to a capability, and capabilities are built, not bought. A structured program where your own people scope, build, and measure automations, with coaching, produces the automations and the people who can build the next ones. That is what the Civic Dialog cohort is, and it is the option most likely to change how the organization operates a year later.

How Civic Dialog's three lanes map

We built our engagements around this decision, so the mapping is direct.

• CoBuild is the consultant who builds in the open: your stakeholders define the requirements, anywhere from none to four of your people build alongside us, and you own the code, the accounts, and the know-how at the end.
• Fractional CAIO is the dev shop with a ledger, kept on: we lead the roadmap, run what was built under a month-to-month agreement on accounts you own, and report the savings monthly.
• Cohort is hiring the capability without hiring: four to twelve of your people learn to build, over twelve weeks, on real work.

All three baseline first and measure after. The comparison page puts them side by side. If you are not sure which fits, thirty minutes on a call is usually enough to tell, and we will say so if none of them does.