Hiring an AI engineer vs bringing in a firm
A loaded salary, four months of hiring, and a market where you cannot evaluate the candidates — against a contract. An honest comparison from someone who sells one side.
Written for
“$180k a year and four months of searching, or a contract. Which?”
We sell one side of this, so read it with that in mind. It is still worth writing honestly, because the cases where hiring is correct are common and obvious, and pretending otherwise would be transparent.
The real cost of the hire
The salary is the number people quote and the smallest part of the decision.
| Salary, senior AI engineer | $160k–$220k, US market |
| Loaded cost (benefits, tax, equipment) | ~1.3× salary |
| Time to hire | 3–5 months, realistically |
| Cost of a bad hire | 6+ months and the project |
The time-to-hire number is the one that decides most cases. If the thing you are building matters this quarter, hiring is not a solution to it — you will still be interviewing when the quarter ends.
The evaluation problem
There is a harder issue that people discover mid-process.
If nobody at your company has shipped production AI, you cannot reliably evaluate someone who claims to have.
The market is full of people who have built impressive demos. The distance between a demo and a system that stays accurate for eighteen months is exactly the thing you are hiring for, and it is invisible in a normal interview loop.
You can partly solve this — have a candidate walk you through a system they shipped and ask what broke after launch. The good ones have long, specific, slightly embarrassed answers. The demo-builders talk about the architecture.
But you have to know to ask.
When hiring is clearly right
- AI is core to the product, not a feature of it. If your product is the model pipeline, that capability belongs in-house permanently and every month you delay compounds.
- You have continuous need. A steady stream of AI work for years justifies the fixed cost easily.
- Somebody senior can evaluate the hire. This is the underrated condition.
- You have the runway to wait four to six months before work begins.
When a firm is clearly right
- One defined project, then maintenance. Hiring a permanent person for a three-month problem creates a different problem in month four.
- You need to start now.
- You cannot evaluate candidates, and would rather buy an outcome than run a hiring process you are not equipped for.
- You want the capability transferred. A good engagement leaves your team with the eval harness, the documentation and the ability to maintain it — which is a reasonable way to buy time until you can hire properly.
The honest middle
The pattern we see work best is neither: a firm builds the first version and sets up the measurement, your team maintains it, and you hire when the volume of AI work justifies a permanent person.
That sequencing means the eventual hire arrives to a working system with evals rather than a blank repository, which makes them productive far sooner and makes them much easier to evaluate — you can ask a candidate to critique something real.
The question to ask either way
Whether you hire or contract, ask the same thing:
Tell me about a system you shipped that broke in production. What broke, how did you find out, and what did you change?
Everyone can describe an architecture. Only people who have run something answer that question well.
If a fixed-scope engagement is the right shape, the audit is the cheapest way to test whether we are useful before committing to anything larger. For agencies, see white-label AI engineering.