Don't hire an AI engineer yet. Do this first.

If you run operations at a small or mid-market company and you are wondering whether you should hire an AI engineer, our honest answer is: probably not yet. Not because the role is useless. Because the sequence is wrong. A full-time AI hire is the third move, not the first. The first move is mapping the workflows you actually want to change. The second is buying a defined outcome and proving that AI moves a number you care about. The hire comes when you have a steady pipeline of AI work in production that needs full-time attention.

We say this as a team that builds AI systems for a living. We have watched companies make the hire early, and the pattern repeats. Six months in, the engineer has shipped a demo, a chatbot nobody opens, and a pile of infrastructure with nothing running on it. The problem was never talent. The problem was that nobody could tell them what to build.

What an AI engineer actually costs a small business

Start with the number everyone quotes. In most markets, a capable AI engineer runs somewhere in the range of a senior software salary and often above it, once you add benefits, tooling, and whatever it takes to keep them when a larger company calls. Call it two hundred thousand a year, give or take, and that is before they have shipped anything.

The salary is the visible cost. The rest is quieter. Someone has to manage this person, and in most SMBs there is no engineering manager who understands AI work well enough to do it. There is ramp time: months of learning your business before the first useful thing appears. There is retention risk, because good AI engineers are heavily recruited and a one-person AI team is a lonely job. And there is the cost nobody prices in: the opportunity cost of spending your one AI bet on capacity instead of results.

A bad tool subscription costs you a few hundred dollars a month and an awkward cancellation email. A bad hire costs you a year.

The first question they ask is the one you cannot answer

Here is how the early hire goes wrong. The engineer arrives, sets up their environment, and asks the obvious question: what should I build first? And the answer they get is some version of "find AI opportunities." That sentence sounds like a mandate. It is actually a confession. It means nobody has mapped the work.

So the engineer does what engineers do. They pick the problem that is most interesting to build, not the one that is most expensive to leave broken. You get a retrieval pipeline with a clean diagram. You get an internal chatbot. You do not get the thing that fixes the invoice backlog or the inbox that takes two days to answer, because finding that thing is discovery work, and discovery is an operations skill, not an engineering one. We wrote about this order in design the work before you build the tech, and the hiring version of the mistake is the same mistake with a salary attached.

This is also the root of most stalled initiatives. The graveyard of abandoned AI projects is not full of bad models. It is full of good builds aimed at the wrong problem, which is why most AI pilots fail long before the technology gets a fair test.

Headcount is a bet. An outcome is a test. Run the test first.

Do this first: the sequence before the hire

The good news is that the alternative is not "wait and do nothing." It is a sequence, and each step is cheaper and faster than a hire.

1. Map three workflows, honestly. Pick the processes that eat the most hours or cause the most misses. Write down what actually happens, not what the process doc says. A structured AI workflow audit does this in days, and the map is useful even if you never automate anything.
2. Fix the data handoffs. Most of what looks like an AI problem is a handoff problem. The report that arrives late and in the wrong format. The CRM field nobody fills in. Fix those first; they are cheap, and any AI you build later stands on them.
3. Buy one outcome. Not a platform, not a headcount. One workflow, one number, one owner. Inbox response time. Hours per close. Deals reviewed per week.
4. Measure it for a quarter. If the number moved, you now know what AI is worth to your business in your own units. If it did not, you learned that for a fraction of a salary.
5. Then decide on headcount, with evidence. At this point the job description writes itself, because you know exactly what the person will maintain and extend.

Notice what this sequence produces that a hire does not: proof. After one shipped outcome you know your data is reachable, your team will actually use the tool, and the ROI math is real rather than projected.

When hiring an AI engineer is the right call

We are not against the hire. We are against the timing. There are clear signals that you have crossed the line into needing one:

• You have two or three AI systems in production and the maintenance load is a real job, not a side task.
• AI is becoming part of your product, not just your back office. Customer-facing AI deserves in-house ownership.
• You have an operator who owns the roadmap, so the engineer will be directed by someone who knows the work.
• The volume of new automation you want per year exceeds what an outside partner can sensibly deliver.

Hit most of those and the hire stops being a leap and becomes an obvious next step. The broader trade-offs are worth thinking through properly; we laid them out in our piece on the agency versus in-house question. The short version: the answer changes as you scale, and starting outside does not lock you out of ending inside. A good partner should leave behind documentation and systems your future hire can take over.

Buy outcomes, not capacity

The reason we push this ordering is that outcomes are simply easier to buy than they used to be. An executive-assistant system we built reclaimed 13 hours per executive per week. An inbox and comms build cut average response time by 68 percent. Neither required the client to hire anyone. Both took weeks to ship, not quarters, because the mapping work up front made the build small.

That is the real comparison. Not "engineer versus no engineer" but "twelve months of salary spent finding the problem" versus "a scoped engagement that ships the answer." The first shipped outcome also does something a hire cannot: it teaches your team what working with AI feels like, which makes every decision after it, including the eventual hire, better informed. That is the kind of work we do across our services: map the workflow, ship the build, then test and iterate until the number holds.

So before you post the job listing, map the work. Fix the handoffs. Buy one outcome and measure it like you mean it. If the evidence says hire, hire with confidence, because you will finally know what you are hiring for. And if you want a partner for the steps before that, this is exactly the work we like doing. Bring us the workflow everyone complains about, and we will tell you plainly whether it needs an engineer, a build, or just a better handoff.