Most "consultancy vs hire" articles are written by one side to sell their option. We do consulting, so read this with that in mind — but we've also told plenty of prospects to hire, because for their situation it was the right answer. Here's how we'd reason through it if it were our money.
Time-to-value: the gap nobody budgets for
A good AI engineer takes time to find. In a competitive market, filling a senior AI role often runs two to four months from writing the brief to a signed offer, plus a notice period, plus ramp-up on your codebase, your data, and your domain. Realistically you're looking at four to six months before that hire ships something to production.
A consultancy that already does this work is productive in week one. At Lumitec we scope in the AI Readiness Diagnostic and then ship on a two-week cadence after that — on your stack, behind your auth, not a slide deck. If your competitive window is this year, the time-to-value gap is the single biggest factor, and it favours the consultancy heavily.
The counter-argument: that gap is a one-off. Pay the hiring cost once and you have permanent capacity. Which is exactly right if your AI work is permanent — more on that below.
The breadth one hire can't cover
Here's the part the job-description optimism glosses over. "AI engineer" is shorthand for at least four distinct skill sets, and almost nobody is genuinely senior in all of them:
- Architecture — choosing the right pattern (retrieval, agents, fine-tuning, plain prompting), and deciding what not to build. Get this wrong and the rest is wasted.
- Production engineering — auth, data pipelines, latency, cost control, and making it survive contact with real users on your existing systems.
- Evals and quality — knowing whether the thing actually works, and catching it when it silently degrades. This is its own discipline, and it's the one most in-house builds skip.
- Operations and on-call — models drift, providers change, prompts rot. Someone has to watch it at 2am.
One hire will be strong in one or two of these and learning the rest on your time and budget. A small senior team covers all four at once because the people are different people. Andrew Walters treats AI as an architecture problem before it's a model problem; the build and ops sides are handled by people who do only that. You're buying a spread of senior judgement, not a single point of it.
This breadth is also why so many in-house pilots stall: the prototype works, but nobody on the team owns evals or operations, so it never crosses into production. (If that's already happened to you, that's a stalled-project rescue, not a hire.)
The cost reality, with the hidden lines included
On paper, a hire looks like the lower outlay. The honest comparison includes the lines that don't show up on the salary:
- Recruitment fees, or months of your own time screening
- Salary, employer's NI/payroll taxes, pension, benefits, equipment
- Four-to-six months of salary before the first production ship
- Management overhead — someone senior has to direct and review the work
- The cost of a mis-hire, which in a thin senior market is a real and expensive risk
A consultancy is more per day and far less commitment. You pay for output, not headcount, and you can stop. The right framing isn't about the lowest invoice — it's what does each pound buy, and how reversible is it. Our own funnel is built around that reversibility: the Diagnostic is free and gives you a full statement of work, a wireframe and an ROI case you keep whether or not you proceed; the first paid work is a small proof of concept, not a year's commitment. Run your own numbers through the AI ROI calculator before you take anyone's word on payback.
Key-person risk cuts both ways
Hire one AI engineer and you've created a single point of failure. They hold the architecture decisions, the prompt history, the reasons behind every trade-off — in their head. When they're on holiday, your AI roadmap is on holiday. When they leave, a chunk of institutional knowledge leaves with them, and you're back to month one of hiring.
A team doesn't have that fragility — the knowledge is shared and documented across people. But be fair to the other side: a consultancy is also external, and a bad one can hold your system hostage. That's why the things that actually de-risk it are contractual and technical, not vendor-loyalty: everything built on your stack and in your repositories, multi-model so you're never locked to one provider, and documentation that means you could bring it in-house — or hire that engineer — later without a rebuild. Those are the questions to ask whichever way you lean.
When hiring in-house is genuinely the right call
We'd tell you to hire, not retain a consultancy, when most of these are true:
- AI is becoming core to your product, not a set of internal tools — it needs to live and evolve inside the team that owns the roadmap.
- You have a steady, multi-year pipeline of AI work, enough to keep a full-time specialist busy and growing.
- You already have engineering leadership who can hire well, direct the work, and review it — an AI engineer with no senior technical manager above them tends to drift.
- You can absorb the time-to-value gap without missing a window that matters.
- You want the capability to compound internally over years, and you're prepared to invest in keeping a scarce specialist.
If that's you, hire — and consider a consultancy only to bridge the gap until they're productive, or to handle managed operations so your in-house team builds instead of fighting fires.
The honest answer for most teams
For most businesses getting started with AI, the sequence that wastes the least money is: prove value first, then decide on permanent headcount once you know what you're staffing for. Engaging an embedded senior team to build production AI and run it lets you get real systems live this quarter, learn what your AI roadmap actually looks like, and make the hiring decision from evidence instead of a guess. If it turns out you need a full-time engineer, you'll write a far better job description for having shipped something first.
If you're weighing this up, the free, no-obligation AI Readiness Diagnostic is the simplest, lowest-risk way to get clarity — you walk away with a statement of work, a wireframe and an ROI case you can use to brief a consultancy or a hire. Or book a 30-minute call and we'll tell you honestly which way we'd go.
Common questions
Is an AI consultancy more expensive than hiring an in-house AI engineer?
Per day, yes; over the engagement, often not. A salary looks like the lower outlay on paper, but the fair comparison adds recruitment fees, employer taxes, pension, benefits, equipment, four to six months of pay before the first production ship, the management time to direct the work, and the cost of a mis-hire in a thin senior market. A consultancy charges more per day but carries far less commitment — you pay for output, not headcount, and you can stop. The right question isn't which costs less but what each pound buys and how reversible the decision is.
When does it make more sense to hire an in-house AI engineer than use a consultancy?
Hire in-house when AI is becoming core to your product rather than a set of internal tools, when you have a steady multi-year pipeline of AI work to keep a specialist busy, and when you already have engineering leadership who can hire well and direct the work. You also need to be able to absorb the four-to-six-month gap before a new hire ships to production. If those conditions hold, hiring builds capability that compounds internally over years. A consultancy can still bridge the gap until your hire is productive, or run operations so your team builds instead of firefighting.
Can't one strong AI engineer cover everything a consultancy does?
Rarely. 'AI engineer' bundles at least four distinct disciplines: architecture (choosing the right pattern and what not to build), production engineering (auth, pipelines, latency, cost), evals and quality (knowing whether it works and catching silent degradation), and operations or on-call (handling drift and provider changes). Almost nobody is genuinely senior in all four, so one hire is strong in one or two and learning the rest on your budget. This breadth gap is the most common reason in-house AI pilots work as prototypes but never reach production — usually nobody owns evals or operations.
See it in practice: MSP service desk AI — a senior embedded team shipping across triage, voice and Teams →